E9.2 ORCH - Performance improvement suggestions

[kaliraj]

Hi,

Requirement: Get Branch plants from UDC and pass to P43090 and process all records(Update process). Here we have to iterate over 2 components,

1. UDC table to process all branch plants
2. 43090 table to process all records of each branch plant.

ORCH design:
First ORCH- Fetch branch plants from UDC
Second ORCH - pass above UDC branch plant and Iterating over 43090 by using rule(checking if record short item is greater than ZERO)

This way am able to process all records of 43090 for all branch plants from UDC. But it is taking more time to process 13K records.

Kindly suggest ideas if the design approach can be changed to improve the performance.


Regards,
Kaliraj

 

[DaveWagoner]

How long to process the 13k records? How many forms is your form request going through? It might be a reasonable amount of time considering the # of recs.

Orchestrator by its nature will in my experience always be slower than direct data manipulation or even z-file processing.

The only thing I can think of is to check if you are iterating over all the records each time you are trying to update only one. Iterate can be tricky

 

[kaliraj]

Initially I had two orchestrations and it took 10 hours. Then I activated Turbo mode, performance was slightly better as it took 7 to 8 hours.
What one thing I did, Instead of defining the filter criteria inside data request, I used query (UDC values) in business view and then used it in data request. This way I was able to design in one orchestration. Now it takes 3 to 4 hours for processing.

Instead of form request I tried logic extension by updating the table directly but still same it took 6 to 7 hours.

Still trying to find for performance improvement ways as I always wonder if this was design as a custom UBE, it will be taking the same amount of time????

 

[Kevin Long]

When people ask me about performance issues, I like to frame my response relative to comparable tools. For example, most orchestrations are built to transact data in JDE using Interactive Applications via Form Requests. Interactive Applications are designed for end users, and they are often used for more than one function. They also have features built for end users such as looking up descriptions or other useful stuff that can create slow down an orchestration. Turbo mode helps with that but there is still quite a bit of overhead. Finally, Form Requests open and close applications each time you call them.

Still, relative to an end-user doing the work, an Orchestration is very fast. 13,000 updates in 4 hours is going to be quite a bit better than having a person do it. There are strategies to help mitigate performance issues.

1. Iterating over multiple levels of orchestrations with many steps will add overhead and slow things down. Depending on what you are trying to do, sometimes that is just unavoidable. Just be mindful to look for opportunities to consolidate work into fewer steps.
2. When creating data requests or filtering data on a grid, always try to leverage table indexes to increase performance. If you are not familiar with indexes, they are used in databases to quickly find information. Think of the index in the back of a book. If you are looking for specific information in a book, and you use the index to find where in the book it is located, your search is very quick. If you must read the whole book to find what you need, the search can take a long time.
3. Reduce the number of forms inside your Form Request. When you record a process using process recorder, you will often go through a few steps to get to the form you need to do the work. Sometimes you can go straight to the form you want, if you know what values need to be populated when the form is loaded.

However, relative to a UBE that is purpose built for a task, an orchestration designed and built using low-code tools will certainly be considered slow. Now we are moving out of the domain of a business analyst/power user who can build a solution that transforms a manual end user task from days to hours with little to no code, and into the domain of a developer who can leverage other tools available in Orchestrator such as the AIS Server APIs, or calling master business functions directly. When you start digging into these areas, you can scale your solutions to work with larger datasets.