Posts

There are times when you may encounter the following error message, “Fld Error: Key Number Does Not Exist”. This can appear when attempting to compile a 4GL program in Lawson, it is possible that the key needs to be added to kndef.

Note that this error message will likely present itself in the XXXX.scr.err file.

To resolve this error, simply follow the steps outlined below:

  1. Login to LID
  2. Run command kndef to define the missing key
  3. cd LAWDIR/(productline)/sdlib
  4. rm *
  5. srgen (productline) (source)
  6. qcompile (productline) (source) (program)
  7. recompile any other invoked programs

Your error message should now disappear and the program should run normal.

If you have added environment users in Lawson, and you are not seeing the new users in listusermap, there’s an easy fix for that.

You will need to run it with the command -a.  This will refresh the cache and show all users in NT order.

listusermap -a

 

If you would like to run other commands, here are some other tips for the listusermap usage:

-a – list all users,

-c – list from cache (Default),

-n – clean up cache,

-u – find user,

-p – find account,

-h – find historical user (NTxxxxxxxx),

-o – show historical user names in list,

-k – list archived user cache

If you receive the error message in Lawson Portal “The Server has not found anything matching the requested URI”, check the WebSphere SystemOut.log for the message “Failed to load webapp: context root /* is already bound.”  This means that one of your WAS applications (most likely the default app) is configured to start before the Lawson IOS application.  To fix this, either delete the Default Application, or configure its startup behavior.  Go to WAS Console > Applications > Enterprise Applications.  Click on the Default Application then “Startup behavior.”  Change the startup order to some larger number so the Default Application will attempt to start last in the order.  Save the changes and synchronize the nodes.  Then, start your IOS application.

 

 

 

Customizing the Lawson Ribbon can be a good idea for giving users a visual cue about which environment they are working in (see screenshot below).

 

Customizing the ribbon is as simple as changing one line of html code.  To update the ribbon image, you will need to open up the index.htm file at WEBDIR/lawson/portal/.  Next, navigate to the “topBanner” element and add a background image (you can use the “find” function to search for this faster if needed), setting the URL to the path where you saved your image (see below).

 

Save your changes and your ribbon will now be a custom view!

Introduction:

Migrating on-premises databases to the cloud can be a complex task, but with the right tools and strategies, it can be streamlined and efficient. One such tool provided by Amazon Web Services (AWS) is the AWS Data Migration Service (DMS). DMS allows you to migrate your on-premises databases to AWS easily and securely, minimizing downtime and ensuring data integrity. In this article, we will explore some top tips to help you make the most of the AWS Data Migration Service and successfully migrate your databases to AWS.

 

Understand Your Database Requirements:

Before diving into the migration process, it’s crucial to have a clear understanding of your database requirements. Take time to evaluate your current on-premises database and identify any specific configurations, performance needs, or dependencies. This understanding will help you plan the migration process effectively and choose the appropriate AWS services for hosting your database in the cloud.

 

Choose the Right AWS Database Service:

AWS offers a range of database services to cater to different workload requirements. Depending on your specific needs, you can choose Amazon RDS for traditional relational databases, Amazon DynamoDB for NoSQL databases, or other specialized services like Amazon Redshift for data warehousing. Understanding the strengths and limitations of each service will help you select the right one for your migrated database.

 

Assess Data Migration Compatibility:

Before proceeding with the migration, it’s essential to assess the compatibility of your on-premises database with AWS services. DMS supports various source databases such as Oracle, Microsoft SQL Server, MySQL, and PostgreSQL. Ensure that your database version is compatible with the DMS service and that any required updates or configurations are in place.

 

Design an Appropriate Migration Strategy:

Developing a well-thought-out migration strategy is crucial for a successful migration. AWS DMS provides different migration types, including full load, ongoing replication, and change data capture (CDC). Evaluate your database size, downtime constraints, and the frequency of data changes to determine the most suitable migration strategy. Consider factors like cost, data volume, and the impact on your production environment when making your decision.

 

Plan for Data Consistency and Validation:

Data consistency and integrity are paramount during the migration process. AWS DMS provides options to enable validation checks and data transformation capabilities. Leverage these features to validate data completeness, correctness, and accuracy before, during, and after the migration. Establish data validation processes and monitor the migration progress closely to ensure a seamless transition.

 

Optimize Network and Resource Utilization:

Migrating large databases can put a strain on your network bandwidth and system resources. To optimize the migration process, consider scheduling the migration during off-peak hours to minimize network congestion. Additionally, allocate appropriate resources to the DMS service to ensure smooth and efficient data transfer. AWS provides guidelines and best practices for resource allocation, which you should follow to avoid any performance bottlenecks.

 

Monitor and Troubleshoot:

During the migration process, it’s crucial to monitor the migration progress and promptly address any issues that may arise. AWS DMS provides detailed logs and metrics that allow you to monitor the migration and identify any potential bottlenecks or errors. Leverage these monitoring capabilities and take advantage of AWS CloudWatch to set up alarms and notifications for critical events. Additionally, refer to the AWS DMS troubleshooting guide and forums for common issues and resolutions.

 

Plan for Post-Migration Tasks:

Once the migration is complete, there are several post-migration tasks to consider. These include redirecting your applications to the new database in AWS, ensuring DNS changes are made if necessary, updating security group configurations, and validating the data in the migrated database. Be sure to have a detailed checklist to guide you through these tasks and ensure a smooth transition for your applications and users.

 

Conclusion:

Migrating on-premises databases to AWS using the AWS Data Migration Service offers numerous benefits, including scalability, reliability, and cost-efficiency. By following the tips outlined in this article, you can ensure a successful migration that minimizes downtime, preserves data integrity, and sets the stage for leveraging the full potential of AWS services. Remember to plan meticulously, validate your data, monitor the migration closely, and take advantage of the extensive documentation and support provided by AWS throughout the process. With the right approach and the power of AWS, you can seamlessly migrate your on-premises databases to the cloud and unlock a world of possibilities for your organization.

When transferring between screens in EMSS, you may encounter the error message “Lawson System Foundation error message “verifyCertificate: CN value: *.<domain> is not in allowed CN list.”

 

The simplest way to resolve this issue, without requiring a restart, is to update the iosconfig.xml.  Add or edit the properties inside LAWDIR/system/iosconfig.xml.

 

1) Add the following property inside LAWDIR/system/iosconfig.xml:

<parameter name=”com.lawson.ios.transform.validatecert” value=”false” />

2) Save the file, wait 15-30 minutes for changes to take effect.

3) To validate the change, run this URL as a Portal Administrator: https://<LSFServer>:port/servlet/SysEnv

 

Another option, that will require a restart of services, is to add the certificates to the transform-hosts tag in the iosconfig.xml file:

 

<transform-hosts>

<cn host=”lawweb1.infor.com” value=”lawweb1.infor.com” />

<cn host=”lawweb2.infor.com” value=”lawweb2.infor.com” />

<cn host=”loadbalancer.infor.com” value=”InforCA” />

</transform-hosts>

 

Add a common name for every host.

 

That’s all there is to it!

If you find that you need to change the driver location in the Amazon Web Services Schema Conversion Tool, or AWS SCT for short, then follow these simple steps below.

 

The first thing you need to do is open the tool and under the settings select “Settings” > “Global settings”Note that the drivers are global settings, not project-specific.

 

Next, select “Drivers” on the left side bar menu. You will need to edit the file path for the database driver you are updating. Once you save it then your drivers are now updated! See the screenshots below for a quick reference for these steps.

 

 

Here are steps to follow if you receive the error message “Registration failed with exception when trying to register a new federated system.

If you receive the below message when trying to register a federated system, open the lsservice.properties file on both servers.  Either add or update the line server.keystore.use.classic=false.

Tue Feb 21 19:26:45.573 EST 2023 – default-1240412896 – L(2) : Registration failed with exception.  Details: registerServer() received Lawson Security Error: Please check log files for details

Error happened on server.com;40000;40001;LSS.

Unable to reach the specified server [server.com;9888;10888;LANDMARK]. It will not be registered.

Stack Trace :

com.lawson.security.interfaces.GeneralLawsonSecurityException: Unable to reach the specified server [server.com;9888;10888;LANDMARK]. It will not be registered.

at com.lawson.security.server.events.ServerServerFederationEvent.processRegisterServer(ServerServerFederationEvent.java:994)

at com.lawson.security.server.events.ServerServerFederationEvent.process(ServerServerFederationEvent.java:115)

at com.lawson.lawsec.server.SecurityEventHandler.processEvent(SecurityEventHandler.java:634)

at com.lawson.lawsec.server.SecurityEventHandler.run(SecurityEventHandler.java:377)

This article covers the steps for configuring Lawson to automatically generate all file types (XML, etc) for each batch job that is run.

 

In LAWDIR/system, you will need to look for a rpt.cfg file.  If the file doesn’t exist, then you must create it.

Next, to generate XML for all batch jobs, you must set RUNTIME_XML to ON.  For CSV, the configuration type is RUNTIME_CSV.

See below for a sample file:

lawdir/system/rpt.cfg

There is no restart or downtime required for these changes to take effect. Simply restart the system and your new changes will be applied to your batch jobs moving forward.

 

Follow these steps to edit the domain name on the ADFS instance:

Update the Domain Name

  1. Open the ADFS Management application from the ADFS server.
  2. On the right, select “Edit Federation Service Properties”.
  3. Change the Federation service name and identifier to reflect the new domain name.

Regenerate the Token Certificates

  1. Open a PowerShell session on the ADFS Server
  2. Run “Update-ADFSCertificate”, which will generate a new token-decrypting and token-signing certificate.
  3. The old certificate will remain primary on the instance and cannot be deleted until a new primary is selected.
  4. In PowerShell, run the command “set-ADFSProperties -AutoCertificateRollover $false”
  5. Now you can right-click the secondary (new) certificates and set them as primary.
  6. Delete the old certificates.
  7. Reset the rollover option in PowerShell: “set-ADFSProperties -AutoCertificateRollover $true”

Deploy the new Server Certificate

  1. Get the Thumbprint value on the new certificate for the new domain.
  2. In PowerShell, run command “set-ADFSSslCertificate -thumbprint <value you saved in step 11>”
  3. Bounce the ADFS service

Your ADFS domain/URL has been updated!