Archive for category: Frontpage Article

To update the database server that your Lawson instance is pointing to, you will need to modify the MICROSOFT (or ORACLE) files for each environment that you are updating.  These files can be found at %LAWDIR%/DATAAREA/MICROSOFT.  Simply change the server name for the DBSERVER value and bounce your Lawson services.

NOTE: This article assumes that your new database server utilizes the same credentials/authorization as the original database server.

 

 

 

Here at Nogalis we perform managed service for several dozen enterprise customers. Most of our customers are either using Lawson V10 on premise or Infor CloudSuite products in the cloud. Our customers vary in their level of complexity but they almost all have several custom interfaces that support the operation of their businesses. Most of these interfaces are built with IPA (Infor Process Automation) or with ION which are both Infor supported products. Here are some examples just to name a few:

• Positive pay interfaces to banks
• Invoice import interface
• Vendor creation interface
• Automated user provisioning
• Employee benefits exports and imports
• COBRA interface
• Batch job automation
• Invoice or Purchase Order Approval interfaces
• Journal entry imports

And many more

Many of these interfaces were designed and developed years ago and have been modified several times since. Unfortunately, the same cannot be said about the documentation that was once made for them if any. In an upcoming webinar and subsequent article, I plan to discuss how to develop accurate, useful, and easy to maintain documentation. But in this article, I want to focus on the reasons why we need these documents because without knowing why we do something, we’re not likely to do it right. The reasons below serve as guidelines for our documentation:

Reason 1 – Supporting the interfaces. This is the primary reason for creating good documentation. The goal of the any documentation should be that anyone can read it from start to finish and be able to support the existing process when it breaks. Therefore, one of the first things we do for our new managed service customers is to create detailed documentation of all their interfaces on our DOCR documentation portal and give them access to it. You can see some examples here. What’s nice about storing these documents on a web portal is that there is a central place for keeping them updated that everyone can contribute to. For support reasons, we make sure that we have a troubleshooting and a recovery section in each of our interface documents.

Reason 2 – Updates and enhancements. We’re routinely asked to update and enhance existing interfaces. While we can dig through the entire code of the interface to find out what every piece does, it is always helpful if some documentation exists that has an overview of the different components of the interface.

Reason 3 – Change Control. As we make changes to interfaces over the years, it is important to document these changes for change control purposes. Having a web-based documentation portal makes it easy to do this as it is the only version of the document that exists, and it is always updated with the latest changes.

Reason 4 – Application upgrades. As we upgrade our large enterprise applications, we always must study the impact of the upgrade on any custom interfaces that we have. The only way to do this quickly is to review the documents and specifically focus on any sections focusing on dependencies, and general data flow. Having proper documentation during an upgrade process can make the difference between a 1 month upgrade and a 6 month upgrade.

Reason 5 – Training and new hires. We pride ourselves in our one-to-one client to resource ratio in our managed service group. That means that for every new managed service customer, we add at least one new member to our team. This new team member goes through a rigorous training that includes reviewing all existing client documentation. This is an indispensable tool for our team as well as any client newhires.

If you need help creating your interface documentation, or to subscribe to our DOCR documentation portal, please contact us here.

If you’re reading this, you must have already become curious about serverless computing or perhaps you just read our other article on the topic. There is no doubt that the future of computing will not have any traditional servers in it. In fact, I would venture to guess that by 2025, nearly every new development project will be a serverless project. This is not very hard to believe given that we at Nogalis have been developing all our enterprise applications for the past year using this paradigm and have yet to come up with a real reason to spin up a server.

There are a few things you need to understand about “Serverless” before you can start your project.

1. Firstly, your current server-bound applications cannot run serverless without going back to the drawing board. In an ideal Serverless application, each request needs to stand on its own. Each request needs to process within a single function, verify itself and its caller’s authentication and permissions, run to completion, and set the states as needed. Your current application doesn’t do that. Your server is likely holding on to user sessions that have been authenticated and running so that it can handle the user’s next request. Without getting any more technical, the important things to understand is a “Serverless” application has to be designed and developed that way, it cannot be ported over magically. At least not today in 2019.
2. Most, if not all enterprise applications deal with a database. AWS has made some great strides in the area of “Serverless” databases and at the current time (2019) offers two database options that are serverless:
   • Amazon DynamoDB – Amazon’s own NoSQL database service
   • Amazon Aurora Serverless – an on-demand, auto-scaling configuration for Amazon Aurora (MySQL-compatible edition), where the database will automatically start up, shut down, and scale capacity up or down based on your application’s needs.

It is obvious that if Microsoft, Oracle, and IBM want to remain competitive in the DB space, they will also have to offer Serverless versions of their database products or go the way of the mainframe. In the meantime, you can build a serverless application, that connects to a server-bound database in order to store its data. We won’t judge you.

1. In a serverless environment, you don’t have any local storage. Because you don’t have a, ummm, server. So, you will need to figure out your storage as a part of your design. No more writing log file to d:\temp. This is one of the biggest reasons your current server-bound application can’t just go without a server. Luckily, AWS offers several API-enabled storage solutions to deal with this limitation. Our favorite is still S3 because of its ubiquitous edge availability, it’s incredible speed, it’s flexible use cases, and its many other advanced features.
2. Last on my list is the method for accessing your compute logic. For this AWS provides their API Gateway which can trigger any of your functions with ease.

Of course, the items above are not the entire story. For instance, AWS SNS is a fully managed messaging service that you can use for messaging. Cloudwatch will help you with event monitoring and debugging. A whole host of applications exist that can help with nearly everything else. In the past two years of developing serverless applications, we have yet to have a need that we couldn’t eventually resolve with AWS available services. I say eventually because our developer brains were accustomed to think of every problem in a very server-centric way. Once you stop relying on the server to solve all your development challenges, you’ll think of some innovative ways to develop your applications that will surprise you.

If you’re considering developing a serverless enterprise application, we’d love to help. Please use the contact us page to make an appointment with someone on our team to discuss your serverless project.

You might come across the need to update a service or identity configuration in ssoconfig (LSF), especially if you have implemented AD FS and need to update your usernames or service URLs. A quick way to update a ssoconfig service is to load an XML file with the updates. Create and save your XML file, set your environment variables on LSF, then run the command ssoconfig -l <password> <filepath>

Here is the file format for a service and an identity (make sure OVERRIDE is set to true if you are doing an update):

 

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

<BATCH_LOAD FORMAT=”” OVERRIDE=”true”>

  <SERVICE>

<HasCredential>TRUE</HasCredential>

<LoginProcedure>Form based</LoginProcedure>

<ID>DSSOIBITEST</ID>

<SvcEntryAttrList>user,password</SvcEntryAttrList>

<LOGINSCHEME NAME=”Form”>

<PROTOASSERT>Use HTTPS always</PROTOASSERT>

<HTTPURL>https://server.company.com:80/sso/SSOServlet</HTTPURL>

<HTTPSURL>https://server.company.com:443/sso/SSOServlet</HTTPSURL>

<PRIMARYTARGETLOOKUP>Verify passwords in Lawson Security</PRIMARYTARGETLOOKUP>

<LOGIN_RDN/>

<NAMING_ATTR>cn</NAMING_ATTR>

<USERNAMEFIELD>_ssoUser</USERNAMEFIELD>

<PASSWDFIELD>_ssoPass</PASSWDFIELD>

<SERVICEURL>https://server.company.com:443/sso/SSOServlet</SERVICEURL>

<LOGIN_SUBMIT_METHOD>POST</LOGIN_SUBMIT_METHOD>

</LOGINSCHEME>

<IdentityAttrList>user</IdentityAttrList>

<CredentialAttrList>PASSWORD</CredentialAttrList>

     </SERVICE>

</BATCH_LOAD>

 

<?xml version=”1.0″ encoding=”ISO-8859-1″ standalone=”no”?>

<BATCH_LOAD FORMAT=”Opaque” OVERRIDE=”TRUE”>

<IDENTITY SERVICENAME=”SSOP” >

<RDID>lawson</RDID>

<USER><![CDATA[[email protected]]]></USER>

</IDENTITY>

</BATCH_LOAD>