c




 






wot notation?

This is the fourth article in a freestyle series on Siebel Workflow.

In this post we will examine a rather sophisticated way to peruse data buried in hierarchical process
properties.

When the  

 executes a workflow process, it creates a wrapper property set to
hold all the process properties for the duration of the process.

This property set can of course be modified when the process is called by providing initial values and it
can also be used as the output property set when the workflow finishes.

However, sometimes the properties are not of a simple datatype such as String or Number but they are
hierarchical, stored as a (set of) child property set(s). A very prominent example is the output of good ol'
!"#$"'s Query method which we all know as "Siebel Message". In fact it's a child property
set with the Type set to "SiebelMessage" which itself has a hierarchy of children of its own.

In our sample workflow we run the EAI Siebel Adapter's Query method in order to retrieve Account
data. We want to use the Account's name to create a custom error message. Here are the steps to parse
the child property sets to obtain the name (and other fields of course).

1. Create a business service step and assign the EAI Siebel Adapter's Query method. Use the typical input
arguments such as PrimaryRowId and OutputIntObjectName.

2. Pass the SiebelMessage output argument to a process property (data type Hierarchical or Integration
Object) as usual.

3. Add a second output argument and assign the following to a process property of type String

SiebelMessage.ListOf[Integration Object Name].[Integration Component Name].[Field Name]

Example (when using the 


"


Integration Object)

SiebelMessage.ListOfInternal Account Interface.Account.Name

This is called the "

" and allows you to access any data stored in hierarchical property sets.

The basic mechanism how to find out the names between the dots is to use the Type values of the
property sets. You can use the workflow simulator watch window or the business service simulator to
get these values. If you are really desparate, try writing the property set to a file using the !"% &
' business service.

Dot notation has proven very useful especially when working with EAI workflows which almost always
engage properties of type Hierarchy or Integration Object. This technique can also be used to pass
parameters to server components, e.g. when calling them asynchronously.

The standard Siebel Repository contains some seed/sample/non-operational/unvalidatable workflows

for the Websphere Commerce Suite (WCS) connectivity which also make use of the dot notation to find
out the Type of the incoming XML data.

A standard/sample workflow using

dot notation

Final Note: You can also use the !"( #) business service (yes the one with the pseudo
XPath syntax) to parse the input property set and unearth data into the parent property set for output.
This post is part of a multi-part series on Siebel Workflow. Previous posts:

Part I: Update multiple records

Part II: Iterate over child records
Part III: Display error messages

And now connect the dots.

Labels: Siebel CRM, Workflow

Š*
+

Siebel fan said...

Hi @lex,

I am frequent reader of your blog - I would say really proffessionally done and thanks for having you.
Usually I dot not post messages, but this time I seem to struggle with the Workflow Utilities and "dot
notation".
I have the following external IO structure and I am tring to reach the "name" element of the "error" IC.
Could you help me a bit, since I tried many options?
IO Name - Response
IC1 Response
IC2 error - having the IC1 as parent
IC2Field name - as element of IC2

Thanks a bunch!

Regards!

January 8, 2010 1:51 PM

@lex said...

Hi Siebel fan,

the best way to get the "path" is to obtain a property set representation of the external IO. For example
you could place sample data in an xml file and load it using the EAI XML Read from File Business Service
in the BS Simulator. Then follow the values of the Type property along until you reach the field.
hope this helps

@lex

January 8, 2010 6:41 PM

Siebel fan said...

Hi @lex,

Thanks for the hint. I manage to create the full path and to extract the value from the IC field. However,
it seems like the Output Argument in the WF where you specify the "dot notation" value, has a
limitation of 75 characters and I can not extract the values for some other properties. If shortening na IO
name and resectfully the path is not an option, can you think of some scrptless way to extract the values
multiple elements/attributes of a SiebelMessage in a single WF step?

Thanks for the help!

January 10, 2010 10:49 AM

@lex said...

Hi Siebel fan,
there are two built-in business services which allow us to read or modify integration objects. EAI Data
Transformation Engine (aka Data Mapper) is one of them. You can convert from one IO instance to
another.
The other useful business service is the EAI Dispatcher.
You could use it to strip off unneded elements from the property set.
However, if things are more complicated, you might want go for a well written eScript business service.
@lex

January 10, 2010 12:05 PM

Siebel fan said...

Thank you for the options provided! Probably I will go with the scirpting solution. As per my knowledge,
the DTE will give me another IO and I will still have to extract the attributes from. The EAI Dispatch Svc
it's a nice solution, but I think will be a bit unnecessarily complicated.

Thanks again for the prompt response in a day like Sunday :-)

All the best!

January 10, 2010 1:01 PM

) 

...welcome back to Part II of our tour de workflow

Let's reiterate the requirement #2

,)

)


"


Sum up the revenue of the current Opportunities for an Account and write the result to an Account
field.

This is the prototype workflow. As in part I, Siebel 8.1 was the implementation platform.

The workflow itself has the following properties:

Business Object: "


Process Properties created: CurrentRevenue, LastRecord, RecordCount, TotalRevenue

Get Oppties Step:

Business Component: -


Operation: .

Search Spec Expression: "[Account Id]='" + [&Object Id] + "'"
Output Args: TotalRevenue = BC Oppty.Primary Revenue Amount
RecordCount = Output Argument /
",

Decision Step Last Record?

yes = Process Property &,0

no = Default

Go to next Oppty Step

BC: -


Operation: /1,
Output Args:
CurrentRevenue = Opportunity.Primary Revenue Amount (1)
TotalRevenue = Expression: 23c,)

45236

,)

4 (2)
LastRecord = Output Arg: / ,(3)
Note: Numbers in brackets indicate the sequence of the output arguments
Update Account Step
BC: "


Operation: 
Field Input Arg: Revenue = Process Property c,)



Note #1: The workflow operates on the "

Business Object with "

as the primary BC and
-

as a child BC.

Note #2: Despite Note #1 it is still necessary to execute a query to get the Opportunites associated with
the Account.

Note #3: The fairly new Siebel Operation /1,(along with its siblings )
, and
.
7(
) has been introduced in Siebel 8.0. It is the first version that allows us to loop
through a record set in a workflow without being outwitted by the complexity of looping. The
NextRecord operation has an output argument of / ,(true or false) which must be used in
a decision step to determine whether the loop has to end or not.

Pitfall #1: Adding up the revenue amount requires two process properties. One to get the field value
from the BC and the other one to serve as the accumulator. Note the sequence in the NextRecord
operation to fill them in the correct order.

This article is part of a series on Siebel Workflow. So far the following articles have been posted:

Part I: Update multiple records

Part III: Display error messages
Part IV: Using dot notation

To be continued in January 2009, please post a comment if you want me to cover a specific area.

@lex

Labels: Siebel CRM, Workflow

8*
+

Karsten Neve said...

Hi @lex,

2 comments:
1. you are already in an instanciated BO for one account, e.g. a query on a child BC will only retrieve the
datasets linked to this account. So I think that the SearchSpec is not necessary.

2. Looping through a child BC is also possible in 7.x - not so stylish as in 8.x, but possible within vanilla.
Take a look at vanilla's BS "SIA BC Utility Service", Method "BCNextRecord" - it's made for this. It also
supports automated summing up of a field's values while looping.

Regards,
Karsten

January 21, 2009 3:14 PM

@lex said...

Hi Karsten,

many thanks for your comment. You are correct that the Search Spec is not really necessary, executing
an empty query would also retrieve the child records.

Thank you also for mentioning one of the many useful business services in Siebel Industry Applications.

There are definitely many ways to loop through a record set without the need for scripting. I remember
using EAI Siebel Adapter and its QueryPage method.

Have fun

@lex

January 21, 2009 7:43 PM

Anonymous said...

Alex,

i would be glad if u can explain me the step by step process of sending an email by workflow(email
notification to the customer or manager).treat this as urgent and post ur expertise.

Thanx
veeru

September 2, 2009 11:33 AM

@lex said...
Hi Veeru,

please refer to the Siebel Workflow Guide. There is an example of using the Outbound Communications
Manager business service to accomplish your requirement.

Have a nice day

@lex

September 2, 2009 12:19 PM

Antonio said...

Hello Alex,
I am trying to build this but I am having difficulties with defining the Decision Step for testing Lastrecord.
I've created a Process Property Lastrecord, type String with Default: False.
In the GetNextStep I've pointed the Lastrecord to the OutputArgument NoMoreRecords.
When defining the Conditions for the decision step I am using the Process Property Lastrecord
AllMustMatch value 'True'. It issues a msg when saving the condition (Error... check with the System
admnistrator)... but somehow when looking again at Edit Conditions the condition is there..

So, is this Lastrecord a string type ? (I was hoping boolean but could not find type boolean)

Would it be possible for you to post the Export file for this sample WF ? It would be of great help...

Txs. for any help

Antonio

December 14, 2009 8:45 PM

suya said...

Defined rules to auto assign sales team members (My auto assign team feature) to the opportunity
based on Org definition. i want to know how should i define the workflow of it i am fresher in Siebel
please help about workflow how to create in detail

November 9, 2010 6:29 AM

@lex said...

Hi Suya,

unfortunately your initial requirements are very unclear. Have you tried to use Assignment Manager for
opportunity team assignment?
have a nice day

@lex

November 9, 2010 8:40 AM

Post a Comment

,

Recently, I had to do some prototyping for typical requirements which led me to the Siebel Workflow
framework as a solution.

As indicated in a previous post, workflow processes (along with the business services they call) account
for almost every piece of functionality and automation in Siebel CRM. So in general it is a good idea to
have an eye on workflow when it comes to automation solutions.

However, there are some pitfalls for the novice developer that often lead to frustration and even refusal
of using workflow.

In this and following posts, I will describe workflows that should serve as examples how to solve
common problems in Siebel.

These are the requirements

9:
 (this post)

Users should be able to enter a search string to retrieve a list of Accounts and the target value of the
Account Status field. The system should then update the Account Status field of all records in the result
set to the target value.

:,)

)


"

 (future post)
Sum up the revenue of the current Opportunities for an Account and write the result to an Account
field.

;:(
 
(future post)
When sending data to an external application fails, notify the user with an error message.

<:,)



(future post)
Use data which is part of a hierarchical property set inside a workflow

I implemented the requirements on Siebel 8.1

Let's have a look at the solution to requirement #1.

To be honest, I was surprised at the

simplicity of the workflow. It is a really nice example how the Siebel framework works.
The workflow is configured as follows:
Business Object: "


Process Properties created: QueryField, Querytext, RecordCount, TargetValue

The first Siebel Operation step is configured as follows:

BC: "

=/&
>
Operation: .

Search Spec Expression: "[" + [&QueryField] + "] LIKE '" + [&QueryText] + "*'"
Output: RecordCount = /
",

The second Siebel Operation step is configured as follows:

BC: "

=/&
>
Operation: 
Field Input Argument: Account Status = Process Property: TargetValue

?9: Too complicated approach

Siebel Operations inside a workflow which operate on the same BC inherit the context of the previous
step, so all you need is one query operation and then the update operation will update all records in the
query result set. That's it.

?: Problems with the primary BC

There is strange behaviour to report when the Siebel Operations use the primary BC of the workflow's
Business Object (Account, that is). I used the "

=/&
> BC instead and it worked like a charm.
Please don't ask why ;-)

?;: Externalize the query string

How in god's name can someone figure out the query string if she/he is not a complete geek?

"[" + [&QueryField] + "] LIKE '" + [&QueryText] + "*'"

is built as follows:

1. Parenthesize the value of the QueryField process property in square brackets

"[" + [&QueryField] + "]"

2. Append the LIKE operator

"[" + [&QueryField] + "] LIKE"

3. Append an asterisk to the value of the QueryText process property and parenthesize it in single
quotes
"'" + [&QueryText] + "*'"

4. Bring all together

"[" + [&QueryField] + "] LIKE '" + [&QueryText] + "*'"

Not too difficult - but devilish

Note that the Siebel Operations have an output argument which is useful to get the number of affected
records.

Several tests showed that the workflow updated several hundreds of records in short time.

This is the first post in a series on Siebel Workflow. More posts in this series:

Part II: Iterate over child records

Part III: Display error messages
Part IV: Using dot notation

@lex

Labels: Siebel CRM, Workflow

*
+

Anonymous said...

good one!!

December 8, 2008 6:10 PM

Samriddhi said...

HI, This is to answer why we have to use "No Link" BCs. Following is the condition on which the
workflow process works in siebel:
"A looping workflow process that processes a batch of records can only loop through records that are of
a non-primary business component of the business object"
Hence we have to use the clone of Primary BC which is called "Accont (No Link)" BC. I hope this solves
the query.

December 12, 2008 9:50 AM

@lex said...

Hi Samriddhi,

that indeed solves it, thanks for the bookshelf quote.

There are some nice examples here:

http://download.oracle.com/docs/cd/B40099_02/books/BPFWorkflow/BPFWorkflow_examples.html

@lex

December 12, 2008 4:22 PM

Dos said...

hi @lex,
Is the query step essentially required? Can't we specify search spec in Update step rather than in Query
step

Thx,
Dos

December 13, 2008 2:03 PM

@lex said...

Hi Dos,

yes you are right, you can also specify the search spec in the Update step.

@lex

December 15, 2008 8:38 AM

Anonymous said...

hi,

If the query returns multiple values, the update only updates the first record found. Why?

February 9, 2010 1:37 PM

@lex said...

Hi Anonymous,
this is a bit unexpected. As indicated in Dos' comment, you could even have only one single Siebel
Operation (Update) step with a search spec.

have a nice day

@lex

February 9, 2010 2:29 PM

Anonymous said...

Hey Hi ..
am also trying this workflow ...in search specificetion of Query Step can we compare two process
properties..

February 24, 2011 1:40 PM

@lex said...

Hi Anonymous,

you can use an expression and the [&...] syntax to combine several wf properties to a search spec.

have a nice day

@lex

February 24, 2011 7:50 PM

Post a Comment
(! 

It has been a while that we had a look at some typical workflow requirements. In our "Tour de
Workflow" we will today look at the following requirement:

(
 

When sending data to an external application fails, notify the user with an error message.

Basically, you will use the Exception Connector and a Stop step. The nice thing about the stop step is
that it throws an exception (RaiseErrorText, that is) which is also recognized by the framework.

Thus you can add your own error messages and (if you run the workflow as part of a 'Pre' event handler)
cancel the current invocation, such as avoiding to write a record etc.

Let's have a look at a simple workflow that retrieves data using EAI Siebel Adapter / Query, converts it to
an XML string using EAI XML Converter and tries to send that XML to an external webserver using EAI
HTTP Transport / SendReceive. Because the webserver could be unreachable, we add an Exception
Connector and a Stop step to the HTTP Transport step.

In this post, I will not deal with the EAI business services as they are well documented in the Siebel
Bookshelf.

The Stop step is documented as well. One major aspect is to select an Error Code of
WF_ERR_CUSTOM_[N] which points to a record in S_MSG. The message text of WF_ERR_CUSTOM_[N]
consists of two characters only: '%1' which is basically a placeholder technique for any text you like.

Pitfall #1: Ensure that the exception connector has a name, otherwise you will not be able to save the
workflow process.

Now you can for example use an Expression to construct your error message as the Input Argument for
the Stop step. Just make sure that you name it %1.
"
 #@ #A$

This table has been used ever since to store translatable messages for several purposes in Siebel. When
Siebel Analytics Applications were developed, Siebel used it to store the translated strings to populate
the session variables referenced in the presentation layer of the rpd file. At some point in time, Siebel
Tools developers acknowledged that fact by renaming the menu entry in Siebel Tools to "Analytics
Strings". This label is still with us, showing how fast things change (There is no "Analytics" with Oracle BI
EE and Oracle BI Applications do no longer use the S_MSG table to store the translated strings...). The
screenshot below shows a somewhat odd combination of different labels for the message table
("Analytics Strings" in the menu, "Localization Administration" in the tab text and "Messages" as the list
label).

Let's go back to our workflow and test it. The stop step's behavior is such that it calls RaiseErrorText,
thus invoking the display of an error message box to the user (or the workflow developer as it works the
same way in the Workflow Simulator).

Final note: The Siebel error code (SBL-BPR-00131) is populated from the S_MSG table as well.

This post is part of a multi-part series on Siebel Workflow. Previous posts:

Part I: Update multiple records

Part II: Iterate over child records
Part IV: Using dot notation

Have fun
@lex

Labels: Siebel CRM, Workflow

*
+

Anonymous said...

Hi Alex,
any way of making a RaiseError out of that RaiseErrorText? Reason being, we are working with a
multilanguage application and would like to use our user defined messages. I was thinking along the
lines of a LookupMessage. However, the workflow expresion builder doesn't offer this function!?
Thanks
SiebDev

July 9, 2010 3:02 PM

@lex said...

Hi SiebDev,

the only way how to this is to create a business service which does the LookupMessage().

I haven't found an OOB Business Service so far.

Have a nice day

@lex

July 9, 2010 8:42 PM

Post a Comment