Wednesday, November 14, 2018

Using Arrays for a Cross Reference Lookup

You may have had to create a flow that needed to look up one value to find another value from a cross reference table. You know that performing this look up as you're looping through your records can really slow down the performance of  your flow.

For example, perhaps you need the full name of a US State and have a crosswalk of the State code and full name:

FL=Florida
GA=Georgia
TN=Tennessee
etc.

When it's feasible (the cross reference isn't so many records to make it impractical), you can query and assign your cross reference values to arrays at the beginning of your flow.

If it is a straight one to one cross reference then create two arrays, like StateCode and StateDescription can be defined on the Start node.

Variable Name = StateCode
Variable Type = Array
Variable Value = [] or new Array()

As you cycle through the cross reference values, assign StateCode[counter]=State Code and StateDescription[counter]=State Description.

StateCode[0]="FL"
StateDescription[0]="Florida"
StateCode[1]="GA"
StateDescription[1]="Georgia"
StateCode[2]="TN"
StateDescription[2]="Tennessee"

While your looping through your records and you come across the State Code, you can now find the State Description value to use.

i=StateCode.indexOf(stateCode)
if (i>=0) description=StateDescription[i]

It is that easy.

Saturday, November 10, 2018

ION Document Flow

A Document Flow moves the Business Object Document (BOD) from one application to another, like the Security User Master BOD from IFS to Landmark multi-Tenant, Landmark single-Tenant, Mongoose, Lawson LSF, etc.

Each of these applications had its own SUM BOD Document Flow created as the applications were rolled out, and after we implemented EAM we followed the same pattern and created a new Document Flow, this one with a Mapping included.

So, each application we were sending the SUM BOD to had their own separate Document Flow to process the BOD and so, we thought, the Mapping from one wouldn’t impact the others. That’s not what we discovered.

We started getting Error BODs because the Mapping we applied to the EAM Document Flow caused a problem with the other systems that couldn’t accept the change to the BOD. It was like the different Document Flows processed the BOD in a series and that’s what it looked like in One View when we reviewed the processing.

How then could we apply the Mapping for EAM without impacting the other applications? It sounds simple now, but we tried a few different things before we hit upon the answer. We needed to create one Document Flow for all of the applications together.

One Document Flow to move the BOD from IFS to all of the receiving applications, with the Mapping for EAM in a parallel stream within the Document Flow.

Saturday, October 27, 2018

Wait, how can I Wait (in IPA)?

You will have noticed there is a Wait node in IPA, but what do you need to know about it? Well, primarily it acts like a User Action, without the action.

You can set the amount of time your flow sits, waiting. Sounds useful? Not so much, depending upon the settings you select. Oh, you can set your flow to wait for 6 hours, like I did for a user provisioning flow, or for anywhere from seconds to days.

But what's the catch? There's always a catch.

Your options, besides the hard coded or variable based wait times, are to keep the Workunit active or not. What does that option do for you? If you keep your Workunit active, then your Workunit will show in a 'Processing' status and you will tie up an IPA node in the Grid the whole time you're waiting.

That means that you are tying up one of the limited IPA Grid nodes until your flow is done. If you have multiple Workunits with a Wait node set to keep active, you will quickly use up all of your available slots and other Workunits will sit in a Ready status until a node frees up.

I don't want to be around when you have that conversation with your co-workers.

So, obviously you don't set your Wait to keep the Workunit active, right? The Workunit will release the IPA Grid node, other Workunits can process, and when the wait time is over, your flow will queue back up and grab the next available IPA Grid node in order to continue.

What happens within your flow if you chose that option? Any non-persistent variables lose their value - they're dumped out of memory when you release the IPA Grid node (like what happens with a User Action).

If you, like me, use JavaScript expressions to build out complicated formulas to assign a variable a value, but don't use the normal Assign step to set this variable to that value, when you hit that Wait then that value gets dumped down the memory whole.

So, I'll make sure I assign the variable it's own value (A=A) to make it persistent. That would work - for your variables. It doesn't help when you're within a node that loops - like Landmark Transactions, Lawson Queries, Data Iterators, or those Counter loops.

If you're in a loop and you hit a Wait - your loop doesn't know where you left off, that's a non-persistent value, and your flow will blow up on you.