The Web Service Node is used for SOAP API calls.  The authentication information can be stored in a configuration set under the Web Service tab.  It is recommended that you create a new configuration set for each interface, and there can only be one Web Service configuration per set.  The authentication options are Basic or WS Security.  Both accept a username and password.

When setting up a Web Service node in IP Designer, select the configuration set that contains the authentication data.  Populate the WSDL tab with a schema file or URL.  That way, you can use the “Build” button to generate the SOAP call.  You can also type the SOAP call directly into the Activity window.

See this article to read more about making external API calls with IPA.

Working with attachments (or comments) to forms Is very simple using the WebRun node in IPA.

The first step to setting up a Web Run node, is to configure the Web Run Connection in your IPA configuration set.  For Internal Lawson commands, this will be your Lawson configuration set (usually “main”).

If your organization is using ADFS for authentication to Lawson, make sure you set up the Web Run Connection using the Lawson thick client site.

Here are the Web Programs used when working with attachments:

  • lawson-ios/action/ReadAttachment
  • lawson-ios/action/ListAttachments
  • lawson-ios/action/DeleteAttachment
  • lawson-ios/action/ChangeAttachment
  • lawson-ios/action/AddAttachment

The Post string should contain the pertinent details relating to the attachment.  All attachments will need a dataArea, filename, indexName, attachmentCategory, and Key values.  The Key values map to the index for the table to which you are adding attachments.  Attachment category is C or U (comment or URL).

When working with specific attachments (ReadAttachment, DeleteAttachment, ChangeAttachment), you will also need to provide attachmentNbr, which is the unique key of the attachment.  When adding and changing attachments, you will also want to provide the ATTACHMENT-NAME and ATTACHMENT-TEXT values.

To configure MSCM 10.x for ADFS, update the mscm.filter.properties file.  Set the service.name.param to the thick client identity, or you can set it to both thick client and SSOP delimited by a comma (i.e. SSOP, THICKCLIENTLDAPLS).  Also, set the lawson.username to the UPN.

Run an updateconfig to set the changes.

NOTE: All MSCM users in Lawson Security must have a thick client identity configured before making these changes.  Otherwise, the user synchronization task will fail in MSCM.

You can validate the change by checking the USER_IDENTITY table in your MSCM database.  This should show records for each user for each identity configured.

 

The Web Run node can be used to make different types of web calls, whether it be to external APIs or internal Infor Lawson commands.

The first step to setting up a Web Run node, is to configure the Web Run Connection in your IPA configuration set.  For Internal Lawson commands, this will be your Lawson configuration set (usually “main”).  For external connections, you will want to create a new configuration set.

If your organization is using ADFS for authentication to Lawson, make sure you set up the Web Run Connection using the Lawson thick client site.

Once you have a Web Run connection, you can set the properties of the node.  The “Configuration name” should be the configuration set for which you just set up the Web Run Connection.  The default is “main”.  If this is an internal Lawson connection, select “Infor Lawson”.  Otherwise, select “External”.  Provide the Web program that you are running.  The Web Run node can be used internally with Lawson to run batch jobs or add attachments/comments to Lawson forms.

See this article to read more about making external API calls with IPA.

lawson-ios/action/SubmitJob?jobName=<!JobName>&jobOwner=<!JobOwner>&wait=TRUE

 

If you are receiving frequent connection failures between IPA and Lawson S3, you may want to configure the connection pooling for S3.

To do this, open the Landmark Grid, and click the “gear” to open the configuration manager.  Click Applications > [your landmark application] > Edit Properties.

Expand “LPA Settings” then “S3 Pooling”.  Click “pfi.pooling.s3UsePooledConnections”

Select “All” for the display complexity.  Click the top LPA option, first column.

Check the box “pfi.pooling.s3UsePooledConnections” and click “Create (or Update) Property”

Now, set the rest of the s3 connection properties.  Best practices are as follows:

Be sure to click the save button at the top of the screen.

What to do if you are seeing this error on a SQL node in an IPA work unit:

java.sql.SQLException: Unable to get a SQL connection from the pool at com.lawson.bpm.processflow.pooling.SQLConnectionPool.borrow(SQLConnectionPool.java:79) at com.lawson.bpm.processflow.pooling.SQLConnectionPool.getPooledConnection(SQLConnectionPool.java:58) at com.lawson.bpm.processflow.workFlow.flowGraph.FgSQL.executeQuery(FgSQL.java:1107) at com.lawson.bpm.processflow.workFlow.flowGraph.FgaSQLQuery.startActivity(FgaSQLQuery.java:149) at com.lawson.bpm.processflow.workFlow.flowGraph.FgActivity.execute(FgActivity.java:947) at com.lawson.bpm.processflow.workFlow.flowGraph.FgProcess.run(FgProcess.java:2201) at com.lawson.bpm.eprocessserver.grid.ExecuteFlowImpl.executeFlow(ExecuteFlowImpl.java:427) at com.lawson.bpm.eprocessserver.grid.ExecuteFlowImpl.restartFlowForUA(ExecuteFlowImpl.java:181) at com.lawson.bpm.eprocessserver.ProcessFlowEngine.execute(ProcessFlowEngine.java:193) at com.lawson.bpm.eprocessserver.ProcessFlowEngine.reStartProcessAt(ProcessFlowEngine.java:116) at com.lawson.bpm.eprocessserver.KBConnectionDispatch.dispatch(KBConnectionDispatch.java:48) at com.lawson.bpm.eprocessserver.KBConnectionDispatch.run(KBConnectionDispatch.java:37) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(Unknown Source) at org.apache.commons.dbcp.datasources.SharedPoolDataSource.getPooledConnectionAndInfo(SharedPoolDataSource.java:181) at org.apache.commons.dbcp.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:701) at com.lawson.bpm.processflow.pooling.SQLConnectionPool.borrow(SQLConnectionPool.java:68) … 14 more

 

To resolve this error, try setting your Maximum Core Pool Size, which determines how many work units can concurrently execute SQL nodes.  Best practices are to set this value to the number of work units that are allowed to concurrently run on your system.

To add this parameter, search for “Configuration Parameter” in Process Server Administration in the GEN data area.  Create the parameter if it doesn’t already exist.

 

Federal law generally requires organizations in regulated industries to have written data retention policies. For example, if an organization operates in a regulated industry where data must be retained for seven years, the company’s retention policy must specify and enforce the specified seven-year retention period. With established policies, organizations can comply with regulatory requirements that require the storage of various types of data. There are many operational advantages to implementing a data retention policy, and many companies have policies in place to ensure they do not violate local, state, and federal laws, as well as various industry regulations.

Both internal and external policies dictate the rules and regulations for data retention, and it is critical that organizations can manage a comprehensive data retention program that meets both requirements. As healthcare organizations create and manage large amounts of electronic data from a variety of sources, record keeping is becoming an increasingly important and complex aspect of information management. Compliance with HIPAA records retention requirements is critical for both medical file storage software developers and healthcare professionals. Given the wide range of varying federal and state health record retention and destruction requirements, it is imperative to follow best practices to ensure compliance with HIPAA and state standards.

HIPAA requires each provider and company that manages protected information to develop a policy for the retention and deletion of medical records. While the HIPAA Privacy Policy does not contain requirements for the retention of medical records, the HIPAA Privacy Policy does include requirements for how data is stored. Statewide, there is no HIPAA medical record retention requirement, and in many cases the state legislature determines the retention period, in which case HIPAA does not take precedence over state law.

State laws may also require medical records to be retained for a longer period than HIPAA retention standards and background data. Any state law that requires a stricter retention period for medical records than HIPAA requirements remains in effect and supersedes federal law. There is actually no HIPAA medical records retention period, which means there is no period of time that a healthcare provider must keep a patient’s medical records before those records can be deleted or destroyed.

Following the HIPAA medical records and record retention period, HIPAA requires the secure destruction of physical and electronic forms of PHI to prevent unauthorized disclosure of PHI. HIPAA record retention rules apply when an entity covered by HIPAA collects information related to medical services or payment for medical services.

Health insurance providers must comply not only with the HIPAA retention rules, but also with the Financial Industry Regulatory Authority (FINRA) rules. In addition to the HIPAA requirements, the healthcare industry is subject to data retention requirements set by the Centers for Medicare and Medicaid Services (CMS) and state laws.

Healthcare organizations are subject to the data retention requirements of the Health Insurance Portability and Accountability Act, and organizations that accept credit cards must adhere to the data retention and deletion policies of the Payment Card Industry Data Security Standard.

For example, for companies in the healthcare sector, one unique regulatory requirement is the Health Insurance Portability and Accountability Act (HIPAA), which governs medical data. There are requirements for how long HIPAA records must be kept while states regulate medical record storage requirements. Although the Health Insurance Portability and Accountability Act (HIPAA) does not contain universal health record retention requirements—instead, they vary from state to state—it does include specific HIPAA-related record retention language. Approved in 1996 to protect health insurance coverage for people who were off work, HIPAA is now known as the document that also guarantees health record retention policies, defines the parties and documents involved, and is the primary document that providers use when creating. internal physician retention policy.

Although HIPAA stipulates that medical records must be kept “for as long as necessary” and does not set time limits, what this means is that healthcare professionals must instead look at the statute of limitations applicable to their condition, as well as the rules required by any regulatory authorities. While record retention requirements are part of the broader HIPAA compliance policy, they should be considered first by your software solution or service provider. In addition to maintaining HIPAA records, insurance companies may be subject to the complexities of FINRA, while employers may need to comply with the record keeping requirements of the Employee Retirement Income Security Act and the Fair Labor Standards Act.

As stated earlier, HIPAA protections apply to many different types of PHI, including patient records, diagnostic images, prescription records, billing records, etc. and require retention of all protected health information for a period of six years from the date of publication, creation or the date of its last effective date, whichever is later. In the UK, the Health and Social Care Records Practice Code of Practice 2016 specifies that anyone working with or in the National Health Service (NHS) is required to keep medical records for 20 years after the last contact with a patient – 8 years after death or up to 25 years after the birth of the last child on maternity documents. Customer records, contracts, financial information, health data, third party data, employee records, spreadsheets, emails, and more are typically subject to data retention policies, regardless of sector.

Organizations should conduct a thorough audit of the data they hold, from patient and employee records to policies and procedure documentation. In many modern health care organizations, the ongoing maintenance of medical records is a discipline that requires specialized personnel and skills. Depending on the industry and business, several laws and regulations may affect data retention policies and may require overlapping or even conflicting requirements regarding how long certain types of data should be retained or what you need to do with it when it’s time to delete it.

If you’re migrating to a new system and need to properly archive your data, you should consider your options. One option is to keep your old system around for inquiry purposes only, though this can prove to be costly and complicated. Another option is to dump all your data into a data lake and worry about it all later, but this fails the most basic test for a data archive solution; accessibility. Luckily, there is a third solution.

The APIX serverless framework, based on the AWS serverless stack has opened up incredible possibilities for inquiry only applications never before possible without a substantial investment in infrastructure. Clients can now provision a web based, lightweight, data archive solution and migrate all their data within days rather than months and at a fraction of the cost of the other solutions with none of the risk. Find out how the APIX serverless framework can help you meet all your Lawson data archive needs and eliminate the legacy servers for good.