IPA Multi-Tenant questions

In planning for Multi-tenant, we are looking at our processes and how we are going to handle the loss of SQL. We have heard a few different things, and wanted to clear some things up.

In multi-tenant, I know we lose the ability to use SQL nodes against Lawson data, but do we also lose SQL nodes entirely (even for non-Infor local databases)? We use local data to take action on Infor processes for provisioning, security, etc…

If we lose SQL nodes entirely, what other nodes are lost to multi-tenant?

Finally, for those who are on multi-tenant GHR/CSF and single-tenant S3, does the landmark that accesses S3 become multi-tenant, or does it remain single and you get 2 landmark instances?

Thanks!

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

russel-cornelson

Good afternoon;

I probably won't have answers to all your questions but let's try to clear things up.

QUESTION

In multi-tenant, I know we lose the ability to use SQL nodes against Lawson data, but do we also lose SQL nodes entirely (even for non-Infor local databases)? We use local data to take action on Infor processes for provisioning, security, etc…

ANSWER

Yes, in multi-tenant you lose the ability to run a SQL node inside a multi-tenant flow. local and remote.

--------------------------------------------------------------------------------

QUESTION

If we lose SQL nodes entirely, what other nodes are lost to multi-tenant?

ANSWER

You also lose the ability to run System Command nodes.

--------------------------------------------------------------------------------

QUESTION

Finally, for those who are on multi-tenant GHR/CSF and single-tenant S3, does the landmark that accesses S3 become multi-tenant, or does it remain single and you get 2 landmark instances?

ANSWER

This is what we call a Hybrid Deployment. In this scenario you should get:

1. MT Landmark for GHR/CSF

2. ST LSF Server

3. ST Landmark Server with S3 dataarea

russel-cornelson

@rmbell

264 processes utilizing SQL nodes is going to be a bit of work; but 24 hours to process seems like an excessive amount of time. I would be interesting in seeing the 24 hour flow to see how it was designed.

IPA is a visual programming tool; and not all techniques are equivalent. There is a few examples where I have shown how I can take the exact same flow running for 20+ minutes down to seconds ... it all depends how it was designed and also what version of Landmark you are on. Alot of performance improvements have been made in this regard over the past year.

Landmark Environment's Replication Set Code is the first place I would look for improvement. This takes care of the major cause of performance issues in running bulk data through an IPA process flow and that is querying the data. But when you build the replication set to generate CSV .... still the smallest/fastest data structure you can achieve incredible performance.

I wrote a KB and had an interactive briefing to cover an overview of leveraging a Replication Set to feed data to a process flow. With appropriate log levels/etc you can spin this data incredibly fast once the call out to pull the data is gone.

1. Workunit Log Level = None; control your logs with delivered javascript function: processlog.info("log message"). This takes the debug portion out of this logging and can make your flow much more efficient; if you handle errors correctly your log can look more like.

processing(1 of 23000) .. success

processing(2 of 23000) .. failed, see PfiErrorMessage

...

2. When spinning through data; use a "Data Iterator" with Input Method = File

**** Defect in reading data that is not using a buffered stream reader ( File is significantly faster for large files )

3. When building an output file use "Message Builder" ... CU28 fixed issue where it was not using a string builder causing a performance issue (30 second flow in tests now down to 1 second)

*** Example I just made a quick test to parse through 723 records.

-- Data Iterator (file input), with a message builder to reorder/rebuild content: 1.45 seconds

-- Data Iterator (file input), with an assign node to reorder/rebuild content: 13.840 seconds

4. REST API

Personally I find the landmark environment REST API's to be faster than Landmark Transaction nodes in most cases. But you can use IPA's web run to connect to the rest api's to get access to this data and its worth testing.

5. LANDMARK TRANSACTION NODE

Note performance enhancements have been made here as well; giving you the option to include data views or not include them. This can have dramatic performance implications in how long it takes to get/return data.

So basically ... if you have your most important flow, or your slowest flow and would like to show it to me I can probably talk with a bit more specifics. These interfaces ... the devil is always in the details feel free to reach out to me:

russel.cornelson@infor.com

All comments

unknown

I second this question. The loss of sql is one of my biggest concerns with moving a multi tenant suite. We use sql quite a bit in our process flows. Losing its flexibility and speed is hard to think about.

I've heard that replication sets can be used in lieu of sql but I just haven't had any experience with replication sets to feel comfortable explaining that.

If an IPA expert or someone on a multi tenant environment could explain a bit in depth to Robert's questions and just how they get at data at a fast speed it would be mightily appreciated. I'm sure Infor must have a solution as there are just too many people using the sql nodes heavy to not have a solid plan.

andy

We're on ST and definitely share your same concerns about the switch to MT. If you're curious about replication sets, I'd recommend checking out KB 2059784. It's a great overview. I'd also recommend checking out KB 2071349 which is an overview of querying Landmark data.

VWAG_EDI_Nachrichten_201406.pdf

russel-cornelson

Sorry for bringing up a topic that is now getting old; but does anyone still have these concerns?

rmbell

We actually are still wondering about this. We reached out to multiple forums, and actually got different answers. One said ALL sql access doesn't work in IPA, and another said local server access would work. Both cited the same document, which had a statement so vague and open to interpretation, 2 folks got 2 different ideas. Losing sql in any capacity is a MAJOR headache for us, and we have yet to see birst in action beyond some pie charts and pretty dashboards, so we don't really know what that is going to do for us. Thanks for picking this question up for us, I will consult my team to see if there is anything here I missed.

jreese

We are looking to move to the cloud at some point so I am trying to determine what won't work on our current flows, once they are moved to the cloud, and how to modify them so we have an easier migration.

russel-cornelson

@rmbell

I would need a better idea of what you are currently using the SQL node for; is it pulling Landmark Data? LSF Data?

russel-cornelson

@andrew-tarver

I am very pleased that you liked the overview

rmbell

Russel, thanks for the straight answers. Some have said local SQL data would still be accessible in IPA through the SQL nodes, and some have stated otherwise.

Per your question regarding what it is used for, we use it for that data, but also for integrating data from local databases for the purposes of reporting, interfaces, provisioning, etc... As a school district, we have had some complicated requests due to complicated business rules(government) and we have found that SQL is FAR more powerful and efficient for these situations.

One example would be our conversion interface for our pay file from our Time and Attendance system to our payroll system(currently Lawson S3). I attempted using LM and LSF queries with javascript and for each loops to get what we needed, but it had to be handled in a record by record basis with nested nodes to get all the necessary data(One of the logic branches looks at the time record, the sub who worked, and the teacher they subbed for. It gets all their active positions to determine how much they make and where the money comes from). It took over 24 hours to churn through all the logic to get our pay file converted. Since SQL has much better handling of joining and converting in datasets, the SQL process works in sweeps of converting the dataset and it is done in around 10 seconds.

We also have comparison reports that we run between systems. Another example would be the state data(they administer our benefits) as compared to our data(we handle the deductions and keep in sync with the state).

We are considering alternate methods of doing these things, the sad truth though, they are slower, less versatile, and far more cumbersome.

Sorry for the prose overload, and thanks for answering these questions for us. I will pass this information along to my team. We have 264 processes that utilize SQL nodes, so we have a LOT to prepare for.

unknown

We have the same concerns about loosing the SQL node. It is so much easier to code with SQL. I feel they are inadvertently increasing the knowledge base needed for a beginner IPA developer, which is going to hurt them in the long run.

Anyway, I'm going to TechEd in April and plan on bringing a couple examples to review and work out how to do the same thing without the SQL node. I'm also going to go to the Birst sessions. I want to see it in action and determine how it is going to help us avoid so many smart notes.

Unfortunately it's a few months away, but I'll post whatever I find out when I return.

unknown

I saw a bit more of Birst at a recent user group meeting and they mentioned that you can bring in other data sources and can still create 'pixel perfect' reports, so it should be pretty usable as far as reporting is concerned. Losing the ability to access external databases would be a huge loss for us as well as that is sometimes the easiest way to interface with other systems.

unknown

I agree that IPA is facing disruption, but ION is architecture of the future. It's represents Infor Open Network for good reason.

ION has two big open source concepts going for it. REST API and OAGIS Business Object Documents. I have completed several flow migrations and so far I have been able to duplicate each IPA Landmark web service call. If one leverages back end services you could push entire workflows to AWS Lambda serverless, something you can never do with IPA. REST API can return JSON, XML or CSV result sets, and opens the door to java, javascript, .net and python development and ci/cd tools such as maven and git. Tremendous processing speed can be achieved through JSON in particular once one understands key values.

There are two broad types of BODs: Infor Application and IMS. Infor Application BODs already support a large number of Infor business transactions. As it stands now Landmark FSM and GHR have replication sets that publish to Datalake which can be connected to Birst. The flexibility of IMS is leveraged through the Enterprise Connector that allows you connect onprem databases to your Cloud Data Lake. Once you have your non infor documents in the Data Lake, you can combine then with your infor documents if you want, then connect your Birst analytics.

Database developers can optimize what database documents are persisted in the data lake, and vastly simplify Birst development, scaling and reporting. Database developers can adopt stored procedures and stream XML documents. The documents can continue to Datalake, or persist within data flows that leverage the xml mapping nodes to support business transaction exchanges between your infor and non infor applications.

Through ION and BODs, Infor has invited other ERPs such as SAP and Workday to participate on their platform, you simply won't get that with IPA.

russel-cornelson

Copyright © 2025 Infor. All rights reserved.