Archive for category: Frontpage Article

You’ve applied a patch to your system and it caused more problems than it fixed or it was not the solution to your problem and there is no point in pushing it to PROD. Today we are going over simple steps to uninstall a CTP which is similar to how you install a patch via lawappinstall.

1. Ensure security is turned off and it is typical to bring down websphere before starting so no user can login during this process.
2. In LID, start with the uninstall command:
   • perl %GENDIR%\bin\lawappinstall uninstall <productline> <patchxxxxx>
3. Run lawappinstall STAGE (optional but recommended)
   • perl %GENDIR%\bin\lawappinstall stage <productline>
4. Verify stage compilation complete:
   • qstatus | wc -l (this command will return the number 4 when compiling is complete)
5. Check for compiling errors:
   • ls %LAWDIR%\<productline>\*\*.err
     • If any errors found, recompile failed programs with this command:
       • qcompile productline SystemCode ProgramCode
6. Run lawappinstall VALIDATE:
   • perl %GENDIR%\bin\lawappinstall validate <productline>
7. Run stgcmp
   • stgcmp list <productline>
     • If the program’s status is FAILED or RECOMPILE REQUIRED, submit the program to the compile queue using the -A option.
8. Finally, Activate
   • perl %GENDIR%\bin\lawappinstall activate <productline>
     • You should see the patch(es) you ran the initial uninstall for, confirm, verify any other prompts.
9. Verify Non-stage compilation (if you didn’t run stage):
   • qstatus | wc -l
10. Turn security on, turn websphere on, run your typical post smoke tests as if you were applying a patch.

Hope this was helpful!

You may have saw our article on how to enable IOS DEBUG logging and realized after enabling it that the log gets spammed quite a bit which may actually make it harder to isolate an issue, especially if other users are currently in the system.

Today we will show you how to turn on DEBUG logging for a specific user to minimize log spam. This tutorial is only for the ios_logging.xml log.

1. Login to your on-prem LSF system (admin rights required)
2. Identify the users RM ID (case-sensitive) that you want enable debug logging for.
3. Locate and backup your ios_logging.xml file in %LAWDIR%\system
4. Edit ios_loggin.xml with a text editor
5. Locate the following section:

<root>
<priority value=”INFO” />
<appender-ref ref=”IOS” />

<!– Appender Filters–>
<!–<appender-ref ref=”PORTAL” /> –>
<!–<appender-ref ref=”DIRECTIOS” /> –>

</root>

Change INFO to DEBUG:

<root>
<priority value=”DEBUG” />
<appender-ref ref=”IOS” />

<!– Appender Filters–>
<!–<appender-ref ref=”PORTAL” /> –>
<!–<appender-ref ref=”DIRECTIOS” /> –>

</root>

6. Locate the following section:

<!– Filter for users  –>
  <!–
<filter class=”com.lawson.ios.util.log.Log4JMDCFilter”>
<param name=”keyToMatch” value=”username” />
<param name=”valueToMatch” value=”lawson” />
<param name=”denyOnMatch” value=”false” />
</filter>
<filter class=”org.apache.log4j.varia.DenyAllFilter”/>
–>

Uncomment this section (remove the <!– and –> characters shown in bold above) and edit the “valueToMatch” value=”lawson” replacing “lawson” with the RM Id of your user, like so:

        <!– Filter for users  –>

<filter class=”com.lawson.ios.util.log.Log4JMDCFilter”>
<param name=”keyToMatch” value=”username” />
<param name=”valueToMatch” value=”ENTER_USERNAME” />

            <param name=”denyOnMatch” value=”false” />
</filter>
<filter class=”org.apache.log4j.varia.DenyAllFilter”/>

7. Save your changes (no restart required and you should see immediate changes)
8. You should now see DEBUG entries in the log for that specific user.
9. Just undo step 6 to revert changes (or revert to your backup file).

Good luck and happy debugging!

When having users test new patches, it’s a good practice to distinguish TEST from PROD visually. This helps users know what environment they’re in as they may be testing after a long day and may think they are testing in TEST when in fact they are changing production data.

This can simply be done by changing a banner color in Lawson Portal.

1. Login to your TEST environment and locate your index.htm file found here: “D:\<lsf_folder>\web\lawson\portal”
2. Assuming your index.htm file is unmodified locate header id=“topBanner”

   

3. Use an online HTML Color Picker tool to choose the hex color you want to appear and replace background-color:#ff8787 to your preferred color hex color code.

Example of how it will appear:

4. Save the changes, clear IOS cache, clear your browser cache, logout and back in to see the change. Enjoy!

In LBI Auditing Part 3b we went over Reporting Service Admin Audit Reports. In this article we will go over the Service Now (SN) portion of reports.

SN01.List of Alerts:

This report allows you to view what user(s) and or group(s) have access to what SN alert/report.

SN02. User/Group Access on SN Alerts:

This is a security report showing user/group access to specific alerts.

SN03.Top Rendered Alerts and their Top Viewers:

This report shows statistics on your most viewed alerts and top viewers.

For more details on these admin audit reports, check out Part 3a “Overview of Framework Service Admin Audit Reports” and Part 3b “Overview of Reporting Service Admin Audit Reports”.