Siebel provides good tools for working with Siebel Hierarchies, e.g. a developer can query Siebel data using the EAI Siebel Adapter business service, transform the queried data into an instance of external integration object using the EAI Data Transformation Engine business service, and then send the result to an external system. If there are no complicated requirements, and the transformations are straightforward, most of Siebel developers can implement outbound or inbound web service in a couple of hours.
However, in case of complicated integration scenarios and order management implementations, you may need to perform non-standard manipulations with instances of integration objects and property sets, e.g. merge property sets, sort a property set, or delete duplicates in a property set. In such cases scripting often comes to the rescue; still, if you’ve spent a lot of time with Siebel, chances are that you can do a lot without scripting. Yes, that’s true, even removing duplicates by some properties or sorting the property set is possible to implement without any scripting at all. But does it make sense to work several hours in a row – or even a full day – just to implement a single requirement? What’s the point? Is it only for the joy of implementing a “scriptless” solution? Maybe it sounded reasonable and you went this way. It might have taken longer than anticipated, but finally you have finished your workflow, and you are proud of yourself. You definitely deserve it – your workflow in Siebel Tools process designer doesn’t fit your wide monitor with huge resolution, it has a lot of decision points, a couple of nested cycles, and many calls to Row Set Transformation Toolkit (RSTT), Product Manipulation Toolkit (PMT), and other mysterious services. But what happens if after several months, a junior developer will be assigned to modify your workflow? Anyway, isn’t your life too short for building such huge and complicated workflows? If it is, why not consider some scripting?
For some simple requirements though, it still makes sense to consider Siebel declarative alternatives to scripting, e.g. you really don’t need a script to create a property set and populate it with some properties there. In this article I will demonstrate some simple “scriptless” tricks for working with hierarchies using out-of-the-box Siebel capabilities. But I will not be touching one of the most famous out-of-the-box business service designed to manipulate property sets – Row Set Transformation Toolkit, as it is an exciting story that deserves to be told separately.
Also, I will not be explaining what the integration objects and property sets are; however, one thing that needs to be casually mentioned is how an instance of an integration object (often referenced as Siebel Message) is different from a property set. Actually it is almost the same, Siebel Message is a property set also, often of type SiebelMessage, with some specific properties, including IntObjectName and IntObjectFormat, and, optionally, MessageId and MessageType. The fact that Siebel Message is a property explains why if a trick works for property set, it is going to work also for an instance of an integration object. However, you have to keep in mind that the opposite isn’t always true!
There are two ways to create a property set, and both involve the famous Workflow Utilities business service:
An instance of an integration object is a property set, too; therefore the ways described above work for them as well. In addition, there are two more options for creating an instance of an integration object:
In some circumstances instances of integration objects are needed to be converted into property sets and back. One scenario could be, for instance, to convert an instance of an integration object into a property set, modify the property set with RSTT, and then convert the property set back into an instance of integration object.
There are several ways of converting the an instance of an integration object into a property set, and the way to be used depends on the desired result, in most cases the EAI Integration Object to XML Hierarchy Converter business service works just fine. It provides two methods with self-descriptive names that could be used – IntObjHierToPSHier and PSHierToIntObjHier. The only thing that should be mentioned here is that PSHierToIntObjHier has a hidden argument IgnoreUndefinedFields that is helpful to avoid an error being thrown when property set contains a property that doesn’t match the definition of the integration object.
There are five ways to do it:
The first four are universal approaches, i.e. those work for both property sets and instances of integration objects, but the last one works only with instances of integration objects. Let’s have a quick look at each of the available options.
This is, perhaps, the most well-known method of extracting property values. To extract the values of Order Type and Order Status properties from the PropSet created earlier, specify the following input and output arguments:
The dot notation method could be used to extract several values in a single workflow step. However, be careful extracting multiple property values like this – if one of the properties being extracted is missing, the extracted value could be … value of randomly chosen property extracted at the same step! Such a confusing behavior has been noticed in different Siebel 8.1 implementations. Also, in earlier Siebel versions the error was thrown trying to extract the value of a non-existing property. Finally, if there are several property sets of the same type traversing the path specified in output argument being found, the extracted value will be returned from the first of those.
In the Siebel Tools process designer the maximum length of an output argument is 75 characters, therefore the method should quite often be invoked several times, e.g. first step extracts the intermediate hierarchy, this hierarchy is provided as an input to the second step, and it then extracts the value of the needed property. Note that this approach doesn’t work if integration object’s name or integration component’s name contains a dot, e.g. looks like this: “7.7 Order Entry Integration Object”.
You might think of Alias type workflow variables as of pointers to a specific property in a property set. To extract the value of the Order Status property from the property set created earlier, create a new workflow variable of the Alias type, and then set the default string for it to “PropSet/Context/Header/@Order Type”. The maximum length of a default string is 250 characters – that should be sufficient for most of the cases. Pay attention that the default string for variables of the Alias type doesn’t support all XPath capabilities, e.g. predicates with search specifications.
If there are several property sets of Header type underneath a Context property set, the “Evaluation of Process Property Alias ‘<?>’ returns multiple values.(SBL-BPR-00271)” error will be thrown.
The values of the variables of the Alias type are not displayed in the watcher window when simulating the workflow in Siebel Tools and in the Workflow Instance Monitor Logs. Also, the value of the variable of the Alias type returned as workflow output argument is not visible by the parent process. You can tackle this by assigning the value of a variable of the Alias type to a variable of the String type.
Examples of input parameters can be seen below:
The notation looks quite promising, however only limited capabilities of XPath are supported, e.g. there’s no support for predicates with search specifications. The XMLHierarchy input parameter is mandatory, but you can use any names for query input arguments instead of MyQuery1 and MyQuery2 given as example, the extracted values will be returned by output arguments with the same names as those of the input arguments:
This approach allows extraction of several values in one call, but if the path is incorrect or property doesn’t exist at the given path, an empty value is returned.
This service also allows extracting several values in one step, the number of extracted values is defined by the value of MaxFieldNames. The value of Hierarchy Node input argument is the type of property set, if the property set with the given type is not found, empty values are returned; and if there are several hierarchies with this specified type, the values from the first one found are returned.
Here the input parameters are given to extract the value from the instance of a PDS Order integration object:
Output argument name that contains the extracted value is Property Value. Therefore in this case only one property value could be extracted in one step.
As you have already learned, all of these methods are quite straightforward, but are not very helpful when you need to do a more sophisticated extraction – e.g., extract the value of the Quantity property from the 3rd line item, or extract the quantity value of the line item with a specific product. When something like this is needed, things are getting complicated, and one of the options could be to iterate over the property set or Siebel Message in a workflow: there are several ways how to do it, but this broad topic requires a dedicated article. In most scenarios having a cycle in a workflow really isn’t a very good option, and it is better to consider something else.
There are, again, 5 ways of doing this:
The first two are universal methods, i.e. those work with both property sets and instances of integration objects, the third works with instances of any integration object, and the last two work only with the instances of Order Management integration objects, i.e. having Header and Line Item components. Now let’s review all of these five approaches one-by-one.
Let’s say that you already have a property set with some populated properties. In this case you still can create new properties or update existing properties using the Echo method of the Workflow Utilities business service. Have a look at the picture below and pay attention to the Sequence attribute: the property set should be specified with the highest sequence number, otherwise an already existing property set will be overwritten!
PropSet passed as an input parameter is the property set created earlier.
The result will be as follows:
Note that you can also set an attribute using “@”, e.g. X.Context.Header@operation.
You can change the value of a workflow variable of the Alias type that points to an already existing property. The change is not shown in the workflow watcher, but it is effective and you can verify it by assigning the value of the variable of the Alias type to the variable of String type. This approach only allows changing the value of an already existing property, i.e. it doesn’t allow adding a new property.
All the components referenced in Hierarchy Path input argument should already exist in an instance of an integration object.. Again, as with extracting the values, an exception will be thrown if traversing the path results in several components with the same name being found.
This works only with the instances of Order Management integration objects, but allows conditional field updates. If ConditionFieldNames and ConditionValues are not populated, every line item that is found will be updated. If there are several conditions specified in a field/value form, the name and value should be comma-separated. Set Multiple Field Values accepts comma-separated lists for Field Names and Values input parameters.
The Y value of Generate New Id input parameter for Set Field Value and Set Multiple Field Values methods overrides the value given in Value or Values input parameter, and generates a new row id values.
Allows setting several values in one go, but updates only Line Items components. Every line item that is found will be updated.
That’s it for now! Don’t hesitate to get in touch if you have any questions and stay tuned for more articles on the topic, including examples of calling RSTT and some other mysterious out-of-the-box business services… Meanwhile, here you can download SIF-files with workflows that invokes the examples described in this article:
|About the author: since 2006, Olegs Koleskins has been working in different Siebel projects, involved in all the phases of Siebel project lifecycle. Since July 2009 he has been working for Idea Port Riga. Olegs’ skill set includes deep technical and functional knowledge of Siebel CRM applications, including EAI Integration and Order Management. He’s also experienced in leading a team of 10+ developers in a long-term Siebel Order Management project.|