Cascading Parameters in Crystal Reports for LBI

When creating an LBI report, there may be a need for a parameter list to be dependent on a previous parameter selection.  The best way to accomplish this in Crystal is to create a cascading parameter. This method works even for multiple-select parameters.

First, create a data source that contains the values you want in your parameters. If your report data source is large, it is best to move that into a sub report, and add a parameter dataset to your main report. In the parameter data set, pull all the records that might be dependent on each other, such as companies and locations.

Create a new parameter called “Locations”. The List of Values should be dynamic. Select a new data source. Set the value and description of the top-most parameter (in this case, Company). Click on the next line in the value box to create a cascading parameter.  In this case, point it at the Location data. Allow select multiple for the parameters where it applies.

Go to Report > Select Expert > Record. Set the Company value equal to the Locations – Company parameter. This way the list of Locations will be dynamically loaded when Company is selected.

When you publish the report to LBI, make sure that you configure the report to use the Crystal Reports parameter page.

How to check historical instances of outgoing LBI smart notifications

Step 1: Login to your LBI server and go to the Tools dashboard


Step 2: Select the Smart Notification link

Step 3: In Smart Notification interface, click the Admin button at the top right:

Step 4: Under Content section, select the Delivered Alert History link:

Final Step:

Select the between dates and click the “Get Delivered Alert History” button to see sent notifications. Below you’ll see all sent notifications on June 26th 2019. You can also filter down on the notifications by Alert ID and or Recipient. You can also redeliver these messages if needed.

How to refresh data for an LBI dashboard report

Typically when you click on an LBI report that’s been setup on the dashboard, it will show you data of the last generated instance.  To add a refresh is incredibly easy.


First login to LBI and go to the dashboard you want to modify a report on. When you click it, you’ll see something like:

To allow the report to refresh data, select the plus sign >> Edit

You’ll see a URL field, all you need to do is add &Refresh=True to the end of the URL and click save.

The URL may look something like this:


Now add %Refresh=True at the end of it like below:




And we’re done! Now the report will always pull up the parameters (if any) so you can see the latest data:

How to Update LBI WebSphere Data Source

If you change the database server that hosts your LBI data, you will need to point your LBI instance to the new server.  This is done in WebSphere.  Log into your LBI WebSphere console, and navigate to Resources > JDBC > Data Sources.  Click on each data source that needs to be updated (LawsonFS, LawsonRS, LawsonSN).  Modify the server name, click OK and Save.

If the user credentials are different for this new data source, from the data source screen go to JAAS – J2C authentication data and update the credentials there.

Save the configuration changes and synchronize the nodes (if applicable).  Go back to the Data Sources screen and test each connection.

Migrate LBI Data to a new Database Server

Whether you are refreshing your test LBI environment or moving all your data to a new database server, you may eventually need to migrate your report data for LBI. This is a relatively simple process, provided the LBI instances using the data are the exact same version and service pack level.

First, back up your LBI databases on the source server and restore to the destination server (LawsonFS, LawsonRS, LawsonSN).

If you are migrating data for one LBI instance, you just need to point your WebSphere data sources to the destination server.

If you are migrating data for a new LBI instance, or for your test environment, you’ll need to update all the services and references to the old LBI instance.  In the LawsonFS database, ENPENTRYATTR table, you’ll need to search the ATTRSTRINGVALUE column for your old server name, and replace it with the new server name.  For example,


SET ATTRSTRINGVALUE = REPLACE(ATTRSTRINGVALUE, ‘source-server’, ‘destination-server’)



After you update those strings, you will need to redo your EFS and ERS install validators to set the correct URL.

  • http(s)://
  • http(s)://
  • http(s)://

Next, log into LBI and go to Tools > Services.  Click on every service definition to look for the source server name, and update with the destination server name.

Make sure your data sources are pointing to the proper ODBC DSNs, and/or add new ODBC connections.  Test and verify all your reports.

Convert LBI to SSL

To convert LBI to use https, the first step is to make sure that you have valid PKCS 12 certificates installed in the Personal and Trusted Root stores on your LBI server. Export your certificate (or have your system admin do it for you) with the public key and private key, and with the full certificate chain.  During the export, provide a password for the certs.

In WebSphere on your LBI server, go to Security > SSL certificate and key management.  Select Key stores and certificates > NodeDefaultKeyStore > Personal certificates. Replace the default certificate with the cert that you just exported. Do the same for the CellDefaultKeyStore (if applicable). Next, under Key stores and certificates again, select the KeyStore and TrustStore, and select “Exchange Signers…”

Add your new certificate from the KeyStore to the TrustStore and Apply. Save the changes. No need to restart your application server yet, we will do that in a bit.

Make sure that your Virtual Hosts contain an alias for the secure port you plan to use. Note that this port must be the WC_defaulthost_secure port under Ports on your Application Server.

In LSF, update your DSP service for LBI to use the new service URL. The service should be set to “Use HTTPS always” and the new service URL should be “

Restart your LSF application server and your LBI application server.

Open your LBI install validator with and make sure the system URL is set to the new secure URL. Submit the new URL. If the certificates are not valid, you will receive an error message indicating as such. Otherwise, there should be no failed tests.

Configure LBI for ADFS

When you configure LSF for ADFS, you will need to make some changes to your LBI configuration so that users will be able to access LBI with the userPrincipalName (

The first thing you need to do is ensure that you have a user in Lawson security where RMID = SSOP = UPN (userPrincipalName).  The RM User that is used to search LSF for LBI users must have an account where RMID and SSOP match.  It is recommended that you have a new AD user created for this purpose (such as lbirmadmin).

Add the new user to Lawson, ensuring that their ID and SSOP values both use UPN.  (  Also make sure the new user is in the appropriate LBI groups for LBI access.

The next change will take place in the sysconfig.xml file located in <LBI install directory>/FrameworkServices/conf.  The ssoRMUserid should be the UPN of your LBI user mentioned above.  After you make these changes, restart the application server, clear the IOS cache in Lawson, and try logging into LBI.

500 Error in DSP Applications

If you update your LSF core technology, and subsequently find that your SSO applications (such as LBI or MSCM) produce a 500 service error, you probably need to update your DSP install on the host server for the SSO application.  Please see our article archive for instructions on how to update and reconfigure DSP.

If you get a “NoClassFoundError”, you may need to add a new class path to your JVM properties in WebSphere.  Figure out which class is missing and add the path to the JVM properties, then restart your application server and check to see if the issue is resolved.

Update DSP for LBI

If you have installed a new DSP for your LBI server, it is very simple to point LBI to the new DSP install.

First, update the sysconfig.xml file located at <LBI Install Directory>/FrameworkServices/conf.  Look for the old DSP name and update it with the new name.  Then, be sure to change the class paths in WebSphere > Your Application Server > Java and Process Management > Process Definition > Java Virtual Machine.  Also, update the Custom Properties at the same location.

Restart the application server.



How to add a user into Lawson Business Intelligence

Lawson makes it incredibly simple to add users to its reporting wing LBI.


First what you want to do is add the LBIUser GROUP to the user in LSA:

This group may be spelled differently but typically it’s called LBIUSER and is defined when Lawson is first setup for your organization.


Once you add this group to the Lawson user. Make sure you save and clear your server cache.


Log in to LBI, go to Tools, and under System Administration click “Synchronize Users and Roles”

LBI typically auto-synchronizes once a day but you can manually do it now and you’ll notice the users and roles will be the same after your sync them.

The user should be able to login into LBI but likely won’t be able to access much if reports, dashboards, and links are assigned additional Lawson groups as a means of restricting access. Again, these are called “roles” in LBI but “groups” in Lawson.


There is also a matter of bursting reports to the user which is another form of security that will be outlined in another article.