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.
That’s really it, the user should be able to log in to LBI, though they may not see much if reports, dashboards, and links are tied to additional Lawson groups (or “roles” in LBI). If setting up access, roles, or bursting rights starts to feel like a headache, our team at Nogalis can step in. We handle the technical side of Lawson so your team doesn’t have to wrestle with it. Whether it’s user management, reporting, or troubleshooting, we keep things running in the background so you can stay focused on your day-to-day priorities.
You can specify the number of records to display at one time.
- From the Navigation menu, select General > User Options.
- Click the Drill tab and select values for these fields:
-
Option Description Number of records to get Specify the number of records to display at one time. You can specify the number of records to display for Drill Explorer,
Select, and List.
Other Options Select between Find and Filter search options. - Click OK. And you’re done. Now you can view the filtered options you set.
That’s all there is to it.
Lawson SSO issue
We are having an issue with ADFS SSO login with Lawson and I need someone to pull the updated metadata.
ADFS auto creates a new ‘secondary’ decrypt and signing cert 20 days prior to expiration so on 8/31-ish It then promotes the secondary to primary 5 days later so that would have been today.
Update the ADFS Token-Signing Certificate
When the ADFS Token-Signing certificate is updated on the ADFS server, it will have to be imported to Lawson and Infor OS.
Someone with admin rights on the ADFS instance will need to export the certificate and provide you with the “.cer” file before these tasks can be completed.
Update the Certificate in Lawson
Log onto the Lawson Server
Start a ssoconfig -c session
Export Services
- Select Manage Lawson services
- Select Export Services and Identity Info
- Choose yes, for all services, None for identities and give it a file name
Check the file for the Service ID name and make a note of it
In this case, LSF_ADFS is the service name.
Go to “Manage WS Federation Settings” > “Manage Certificates”
Select “Delete WS Federation Certificate”
Select “Create certificate for “WS Federation”
Select “Delete IdP certificate”
Enter the service name of your ADFS service
Select “Import IdP Certificate”
Enter the service name of your ADFS service
Provide the full path where you have the token-signing certificate saved
Verify External Portal work (goes through ADFS)
Update the Certificate in Infor OS
Log into the Infor OS server as the LAWSON user
go to STSAdminUI
Click on idP Connections
click on Edit
Scroll down and you will see that the signing cert has changed
Go back to the top and click on the world
Enter the URL that Admin provided and click on OK
Click on save
Now test your connections
Summary of issue: When working on a Lawson IPA Flow issue, there was an IPA Webservice Node call that grabs XML data. This data was then fed into an IPA XML Builder/Parser node and begin to throw an “’X’ is not defined” error.
After our IPA WebSvc node “getNewlyAddedContacts” made an API call to return records. It then fed to an XML Builder/Parser node and threw a “’P1’ is not defined error”. We will explain why below.
Even though the “contacts” information was being called successfully, one of the records had bad data.
This record specifically had a { (bracket) in one of it’s fields and this somehow got encoded as {
Which resulted in the XML Parser Node in IPA to fail with the “P1” is not defined error.
So, if this happens to your process that is calling on XML formatted data, search your logs for the specific record that “is not defined”.
Good luck!
When working with large databases, performance is always top of mind. A common question that comes up is whether the number of columns in a table impacts query speed. For example, if you have two tables—one with 10 columns and 100 million rows, and another with 100 columns and 100 million rows—would querying them perform differently? The answer is yes, and here’s why.
Data Volume and Size
The most obvious difference is data size. A table with 100 columns will typically be much larger than one with 10 columns, assuming the column types are comparable. Larger data means more I/O, longer read times, and potentially more strain on memory when queries are executed.
Indexing
Indexes play a major role in query performance. Maintaining and using indexes across 100 columns can be more complex than doing so on 10 columns. If indexing isn’t carefully optimized, the larger table can suffer from slower lookups and more overhead.
CPU and Memory Usage
Querying a wider table generally requires more CPU and memory, particularly if the query involves joins, aggregations, or sorts. Pulling 100 columns into memory is simply more work than pulling 10.
Query Optimization
The database’s query optimizer has to consider more factors when dealing with a wider table. More columns mean more potential execution paths, which can lead to longer planning times and less efficient execution if not managed carefully.
Network Latency
If results are returned over a network, the number of columns requested also matters. A query that selects all 100 columns will send back significantly more data than one with 10, increasing network transfer time and bandwidth usage.
Storage Considerations
Finally, the underlying storage system makes a difference. Wider tables consume more disk space and can be slower to scan, depending on how the database engine stores and retrieves data.
Key Takeaway
Both tables have the same number of rows, but the table with 100 columns will almost always require more resources and may perform slower than the table with 10 columns. This doesn’t mean wide tables are always bad—they may be necessary for certain use cases. But when designing schemas, keep in mind that fewer, well-structured columns usually lead to more efficient queries and easier optimization down the road.
Summary: A user was trying to make a change on PR37.1 but received error: “User not authorized for batch. Contact Payroll”
On PR37.1, the user was trying to make a change:
Received the error at the bottom left: “User not authorized for batch. Contact Payroll”
When checking the user on Time Batch Control OCBC.1, we noticed the user was setup:
Here is the users listusermap, but notice that it’s capitalized, but on OCBC.1 it’s lower case.
Turns out that was the issue, removed the users NTID from Time Batch Control and re-added their NTID to match the listusermap case. nt000003fe to NT000003fe
The user was then able to make a successful change on PR37.1
