This content has been marked as final. Show 4 replies
why not just going simple?
i.e. add a step at the beginning and at the end to create and clean-up a blocker-flag i.e. by using a RDBMS-Table and inserting a row or by simply creating a text file using OdiOSCommand (if wanted you could i.e. put your session_ID into the above textfile for better troubleshooting)
and make use of OdiFileWait (or OdiWaitForData in case of an RDBMS-Table) to make sure only one of those jobs is running at any given moment.
I wish ODI can handle such kind of thing by its own but its not. I am expecting that ODI (in coming versions) should detect if one scenario us running simultaneously in multiple sessions then it should itself takecare of the temp tables. As of now appending session id is the only option i guess.For this you have to modify the KMs. :(
Instead of appending the complete session id you can append the last 5 digit only.This should work fine.
We use Wait/Notify procedures communicating with a central Listening procedure via UDP.
The central Listening procedure receives completion Notify events and, using entries in an action table, forwards initiation commands to Waiting processes and scenarios.
This works for ODI and non-ODI processes and across platforms.
The llistener records traffic in a separate table which is useful for reporting, analysis and error recovery.
The ODI Wait/Notify procedures and central Listener are written in a few lines of Jython.
One central Listener can forward commands to another central Listener, so the command structure can be as complicated as you like.
Indeed, if an action item forwards a command to it's own listener, you can get a pretty dramatic loop.