The Powerful Info button in ServiceNow Tickets

, ,

In ServiceNow there are a ton of buttons when you first start using it and it can be overwhelming and easy to ignore them at first.

When a ticket finally makes it to you, it might be in a hierarchy of other ticket types (requests, changes, tasks, incidents).  For my example it’s under the “Request Item” field.

The Request Item in our case is another ticket type in the hierarchy and usually has more detailed of what the task is to complete this ticket.  A useful button that you may overlook is the “I’ button which is essentially an Info button with tons of helpful information.

This button shows a plethora of information that may be relevant in resolving the ticket or task and essentially allows you to view more specifics about the ticket without just searching for it elsewhere in ServiceNow.

All these Info buttons could be useful, some give detailed user information while others give location info.  It saves a bunch of time. Hope this was helpful!

Easily Create Upload Formatted Documents from Existing Spreadsheets

, ,

Often people have spreadsheets that they are using for data gathering and don’t want to change the familiar format to accommodate a Lawson Upload.  Especially when it is a multi-tab spreadsheet that data can change depending on which tab you are pulling data from. No problem. Using advanced Excel techniques can pull the information from the specified tab in a format needed for uploading.

In this example, time attributable to projects is entered on a multi-tab spreadsheet one tab per period.

As the tab changes on the Instructions tab, and after the macro finishes by clicking n the Create Upload button, the total count and amount can be validated that the process worked as expected.

Each tab can have a different order of users and/or different active projects across the top.

As the tab changes on the Instructions tab, and after the macro finishes by clicking n the Create Upload button, the total count and amount can be validated that the process worked as expected.

The macro extracts the non-zero time entries and formats the data in a way that the Upload Wizard can then load the data into Lawson. 

How to write fail safe stored procedures

, ,

We normally write stored procedures for nearly any transaction that has more than one component to it. For example, creating an invoice record that has many lines would require you to insert a record into a header table, and multiple records into a detail table. But what happens if you insert the header and one of the detail records fails to get inserted properly. In these cases, you’re usually greeted by a SQL Exception and error out. However, depending on how you write your stored procedure, you might now have one header record and some of the detail records in the database. In some cases this might be okay, but in most cases it is not and the preference would be to avoid inserting any of the records if even one of them fails. Luckily MySQL provides a really great solution for this problem.

You simply define the action to be taken once the exception is encountered, in our case a rollback, and then you start and end your transaction in between a “START TRANSACTION” and “END” directive as shown below:
BEGIN

    .. Declare statements ..

    DECLARE EXIT HANDLER FOR SQLEXCEPTION 
    BEGIN

          ROLLBACK;
    END;

    START TRANSACTION;

        .. INSERT  ..
        .. UPDATE  ..
        .. SELECT  ..

    COMMIT;
END

Monthly Server Healthcheck Section Overview

, ,

Nogalis offers monthly server healthchecks that informs clients of any current or potential problems in Lawson for both PROD and TEST servers. The healthcheck covers error logs, smoke tests, patches, LID functionality, portal check, database integrity, and many other sections (26 total) which will be briefly outlined here.

You can visit https://nogalis.com/docr/demo_hc to view a demo healthcheck for yourself.

  1. Summary

    This is arguably the most important section of the monthly healthcheck. If there is one section to read, it should probably be this one as it brings to attention the most pressing needs of all the other sections. There is also a handy letter grade assigned each month so you can quickly keep track of the overall health of your server!
  2. Recommendations

    This section has all the combined recommendations from the other sections of the healthcheck. It is divided into three levels of urgency so the client can decide what to focus in on.

  3. System Layout

    System hardware and OS information.

  4. Component Versions

    Lawson components version information. If server versions start to fall significantly behind latest versions, recommendations are made.

  5. Application Versions

    Lawson application version information

  6. Programs with Errors

    Any .err files found in the Lawson directory are pointed out in this section. As with any section, further investigation into any issue can be requested by sending an email to the Key Contact.

  7. Custom Programs

    List of custom Z/Y/X programs

  8. CPU Performance

    Tested while idle and under duress. Just a very rough idea of the CPU performance.

  9. Disks Report

    Report on the free space available of the different drives on the server. We make sure to point out in the Summary and Recommendations sections when a drive is getting dangerously low on free space.

  10. Purge Recommendations

    The disks report is followed by purge recommendations where we point out certain things that could be deleted to free up some space.

  11. Java

    Java settings information/recommendations and a screenshot of the jconsole.

  12. licsta

    Summary table of current licenses (viewable in LID)

  13. Error Logs

    Every month we grab these 6 important logs to analyze them for current errors. These errors are pointed out in this section so that the client can determine if they are worth investigating or not.

  14. Smoke Tests and Component Testing

    Various smoke tests with LID, Lawson portal, and various URL tests

  15. Recurring Job Listing

    Simple table listing of recurring jobs. One of the sneaky benefits of having all this information in one healthcheck page is that it allows for a quick search for any terms using the DOCR search bar on the left panel.

  16. Waiting Jobs

    List of waiting jobs

  17. Database/Table Review and Sizing

    This section displays the 10 tables with the largest number of rows for each of PROD/LOGAN/GEN. A quick overview of this section might lead to decisions to purge certain tables for example.

  18. Database Integrity Check

    Summary of database integrity check performed through LID. Any errors here are pointed out in Summary/Recommendations.

  19. Printers

    List of printers and their commands

  20. Work Directory Review

    Overview of Lawson work folder

  21. Print Directory Review

    The Lawson print directory list by user. This information could possibly be used to purge old users/records.

  22. Security Analysis

    Security analysis performed using LSFIQ
    (1-click Lawson security audit and reporting tool: see https://www.nogalis.com/nogalis-products/lawson-security-with-lsfiq/ for more info.)

  23. Patches Installed Report

    List of latest patches installed on this server.

  24. Source Versions Report

    The source versions report is in a zipped file available to download in the Related Files section.

  25. Related Files

    Any related files related to the healthcheck are in this section where they are available to view or download.

  26. Key Contacts

    If you have any questions about the healthchecks or would like to request an investigation into some error discovered by the healthcheck, please contact anyone in the Key Contacts section with your questions.

What does deljobhst really do?

, ,

Often our Lawson print queues get cluttered and out of hand.  Lawson’s deljobhst command is a really great tool for cleaning up your batch jobs.  It can clear the clutter from your user’s print managers, as well as free up some space on your server.  Run this command in LID.

For each of these commands, you must provide a “ToDate” in MMDDYY format.  So, if you give it an end date of 033119, for instance, you would delete all the selected job history up to March 31, 2019.

You also have the option of providing a user’s account so that you just perform the delete for a specific user.  There is also a from date option that allows you to manage job history for a specific date range.

We recommend setting up some of these commands on a schedule to keep your Lawson server happy & healthy.

Here is a summary of the command:

The -w option will delete all waiting jobs, so jobs in recovery and jobs with Invalid Parameters.  After you run this, there will not be any jobs listed in the waiting queue for the specified user (or all users) up to the specified run date.

The -c option deletes all completed jobs.  This is a great way to clean up user’s job schedule print manager lists.  This action removes the data from the QUEUEDJOB table.  It does not remove print files.

The -r option removes all the print files associated with batch jobs, that were created up to the specified to date.  This will help keep your server from getting too cluttered.  Make sure you back up your print directory, especially if you have a retention policy at your organization.  If you run the command so that it deletes ALL print files (so delete everything up to today), it will delete your entire print directory.  Don’t panic!  It’ll be created the next time a user runs a batch job.

Designer Series – JSON Converter Node

, ,

The JSON Converter node can be used to build a JSON object from CSV or XML, or to convert a JSON object to XML or CSV.

Under the input tab on the Properties, the input could be output from some other node, a variable, or a text string.

The output from the converter node can be used to saved to a file, in a data iterator, or in other reader nodes in your flow.

IP Designer Series – JSON Builder Node

, ,

The JSON Builder node can be used to build a JSON object, which you can use later in your flow for reading or sending out to a server using a web call.

Under the input tab on the Properties, the input could be output from some other node, a variable, or a text string.

The output of a JSON builder can be used to send a JSON web call, or it can be read similarly to the JSON parser output.

IP Designer Series – JSON Parser Node

, ,

The JSON Parser node can be used to parse JSON data, either from a local file or from a response from a Web API.  The steps are very similar to getting XML data from a web API.

Under the input tab on the Properties, the input could be output from some other node, such as a file access node or Web Run result.

For the output, if you provide a sample file with a JSON response, that is an easy way to get the syntax for the variables coming across in the JSON response.  You can click “Set Variable” to see the syntax, and you can select “Export Variables” to get a file with the syntax for all variables in the sample file.

Use this output syntax to set variable values to use later in your flow.