Imagine yourself in the middle of the integration process. You're staring at a requirement asking you to update, let's say a SiebelMessage, that was just queried, and is being processed by one of your workflows in order to be consumed by some 3rd party system somewhere around the edge of the universe. But the update is not just an ordinary update, it has conditions. For example, “Action Code” of the Order Line Item to be passed for further transformation has to be “Add”, and the product of the same OLI has to be some kind of a phone, any kind you can imagine. Add a bit of sorting, a teaspoon of “Get The First That Matches The Condition”, a drop of “Delete That Element”, and you have your recipe of a complex and painful solution you are about to implement.
It will, most probably, use many kinds of different approaches: DataMaps, Scripting, Querying here and there, and you're going to feel lucky if you had a couple of “light” components in order for the query to avoid pulling ALL of the stuff from the database. Sometimes you can even pull out some heavy weaponry like RSTT, or one of your secret undocumented methods you have found debugging some Pre- method in a service or BC.
But let's admit, it would just be super-nice to have One Ring To Rule Them All. And meanwhile you have to repeat over and over again: Script-DataMap-Query-RSTT-WhateverElse. Be it between environments, or between projects – you're going to face similar challenges. And we're not mentioning the docs yet! Docs that your colleagues are going to read, when you are on vacation, and the solution needs to be in place “yesterday”.
First, I will ask you to breathe in, breathe out, and admit that unless you’re not planning to remain stuck in a Junior Developer position forever, sooner or later you’re going to face something similar to the situation described above.
Then it would be great to exercise your memory a bit and try to remember the last time you’ve seen a workflow being invoked by something other than “Workflow Process Manager”. To be honest, I can’t recall a single case, which, of course, does not mean, that there aren’t any.
The reason I’m asking about the “Workflow Process Manager” is simple. You can easily find it under the “Business Service” view in the Tools, meaning that every time you call a workflow, you are dealing with Property Set both on the input and the output of the call.
It can be called anything within the documentation: Hierarchy, XML, SiebelMessage, etc. But in the end you’re dealing with the Property Set, and that’s it.
Facing this fact, don’t you think it would be nice to have a tool that would allow dealing with the Property Set in a bit more friendly way – compared to what is available in the workflows currently?
And by “friendly” I mean, for example, an easier access to properties and values in an XPath’ish way, i.e. something along these lines:
//Line Item[@Action Code = ‘Add’ or @Product = ‘Mobile Phone']@Id
Wouldn’t it be great if you could do a single query, or no query at all in case when you receive a message from the outside of Siebel, and do all the transformations required in a couple of steps?
Easy migration, no recursion, powerful conditions, sorting, addressing child by an index within a workflow – meaning you can construct loops, as in the example above, allowing you to return an MD5 of a PropSet to see if there have been any changes to it within the process, and save a little bit more time by avoiding the need to commit to a DB, and many other things… That’s what the tool that we have developed does for you.
To be short, here is the piece of documentation:
PropertySet Utils is using custom implementation (in the same BS) of Xpath (http://www.w3schools.com/xpath/xpath_syntax.asp) language.
Supported XPATH language functionality:
All of the examples are shown for the following PropSet:
Everything said above boils down to the following: currently there are projects in our company that have their Order Management and Integration functionalities taken over by the PropertySet Utils by around 30% without a single fail from the service side.
I am not saying that it is a panacea for every single task, but it definitely speeds up the development process and improves overall application performance as well. You do not need all the different services for doing one small thing with your data, like “Inbound E-mail Database Operations” for some cases, RSTT for others, and SIS OM PMT for another occasions. You have it in one place with simple and dynamic inputs and outputs, logging, etc.
If you feel like someone is developing a single integration task for a third week in a row, and it seems too long for you, perhaps the time has come to get in touch – and we will see how we can ease your pain!
