
Problem
I'm not sure how Integration Link versions are selected — or how the Version Filter impacts on execution of the Integration Link.

Solution

Here's an example Integration Link:

If you start this Link, all process instances will use THIS processor chain.
Most important to note is that the script stating "ConvertServiceToProcess($response)" will be executed for all calling process instances, regardless of when they were started. This is one of the key features of the Integration Link.
A common misconception is that the script will be versioned, meaning that an old process instance will retrieve an "old" version of the Integration Link model and execute the script that was defined in that old version. Be aware: This is not how it works!
In your process you use the Integration Link Task:

The "Version Filter" property is used in the Integration Link during execution of the call to select referenced Business Objects.
Remember: It is NOT used for selecting the Integration Link version!
Another common misconception is that the version filter selects the Integration Link version. Again, be aware that this is not how it works! There is ONLY ONE version of an Integration Link running at any time for ALL process instances.
So, how does the Version Filter impact execution of the Integration Link?
"Same Version (inherited)"
Uses the Version Filter of the process instance to select Business Objects. In the example above it is used to select the definition of the Script Function "ConvertServiceToProcess". This allows old processes to work with the mappings from/to process structures that were "active" when the process instances was created.
Problem: If the signature of the script function changes and the Integration Link uses that new signature, old process instances call the function with the wrong number of parameters. This happens because the version filter that is applied selects an old script function version which does not have the same number of parameters. It leads to an exception, and possibly to a suspended process.
"Newest Committed Version (Timestamp)"
Creates a timestamp filter with the current system time. The filter is then be used to select Business Objects. This allows old processes to work with the latest/newest mappings from/to process structures.
Problem: The latest script function implementation will always be called so there are no signature mismatch problems. However, the structures which are returned to the process might not be 100% compatible with the "old" model that the calling process instance requires.
Recommendation
It is up to the solution architect to select the most suitable strategy.
In case the "service structure changes" vs "process model changes" are small, I’d go for the "Newest Committed Version" filter: This gives you most natural control over how structures are converted as the same strategy is used for every single callee. Fixes can be applied easily just by changing the involved script functions and Integration Link.
On the other hand if "service structure changes" vs "process model changes” are going to be large — for example, if the service is new and still under development – I’d go for the "Same Version" filter. This filter takes the specific conversion strategy which was built for the specific process instance version.
Attention: If you need to call different versions of the service for different process instances, this cannot easily be done using Integration Links. Integration Links are best used in handling cases where you deal with non-versioned services.

Comments (0)