Siebel Runtime Event and Workflow Process

In Siebel world, Runtime Event (RTE) and Workflow Process seems to be very good friends. Both understand each other pretty well. Whenever there is a need to implement any functionality on based of some trigger, these two friends comes hand in hand. I usually make use of both of them most of the time to make a good solution.

Few things to keep in mind when we use them for any requirement:

1. If a workflow process needs to be invoked synchronously like, via button click on the UI or some action done by user, RTE can be used. The best part is if the Workflow is also based on the active business object, system will automatically set the "Object Id" process property with the Row Id of the primary business component on UI. Moreover, the complete context of the UI handed over to the workflow.
   
   Note: RTE will not get invoked if the business object, on which workflow is based on, is different from the UI context BO. 
   
   
2. In the scenario where point#1 can't be used due to any reason i.e. workflow is not based on any BO, then the only way to pass the Row Id or any other field values of the current record to the workflow is via setting the profile attributes. In the RTE action set, you can set the profile attibutes as the first step and in the next step call the desired workflow. Then inside the workflow, you can read the profile attribute values.
   .
3. One of the tracking feature that OOB provides is, if you have "Monitoring Level" set to "4 - Debug" for a workflow process, and if that workflow process being called from RTE then system automatically add a new property named "Triggering Event" with the Row_Id of RTE. So it becomes easy to track the triggering event.

How to send email containing multiple child records data?

I am pretty sure you will find this post very interesting, if you ever get a requirement to send a email in HTML format and email should have the details of the child records(dynamic data) as well.

XSLT (XSL Transformation) can do wonders for this kind of requirement where the basic idea is to get data in XML hierarchy from Siebel (which you can easily do via EAI Siebel Adapter and convert it into XML) and apply the XSL transformations to get the HTML output. And as far as you know how to play with HTML and XSL, you can create any kind of email format that you like to see. All you need is to use EAI XSLT Service business service with method Transform.

Below picture might give you some idea of it:

To understand the concept, let suppose:
1. As soon as an Opportunity gets submitted, you are required to send an email to the Sales person to inform him.
2. Email should have the details of child records created under that Opportunity.
3. Email should have some kind of formatting so that it looks good and eye-catching.

You might be thinking what is a big deal in it and why should I even use the XSLT (new term for lot many people) for it? There is a simple reason behind it, there is NO OOB way available in Siebel (as far as I know) by which you can include the data from Child records (multiple) in the email.

Let me first show you the proof-of-concept and later we will discuss about the technical solution.
1. I have below opportunity created with 2 records of Opportunity Products.

2. It has also 3 Quote records created under it.

3. As soon as Opportunity get submitted, system is required to send the email to the sales person.
4. Here below is the email, I would like to receive:


If you find that interesting, keep reading for the technical details of it.

Pre-requisite
Please note that for this demo, I have used a Integration Object (Opportunity) based on Opportunity BO with having only 3 ICs configured: Opportunity, Opportunity Product and Quote. And include only those fields whose values are required in the final email, for eg: Oppty Name, Product Name, Net Price, Quote Name etc. (Please refer the first picture of this post, XML part)

Technical Solution
1. Call a Workflow (based on Opportunity BO) as soon as Opportunity gets submitted.
(Note: System will automatically pass the row_id of Opportunity to "Object Id" process property of the Workflow Process)
Here below is the WF snapshot.

2. Process Properties

3. Step Details:


Code for XSLTBuffer
<?xml version="1.0" encoding="UTF-16"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:template match="/"><html><body><h2>You have got an Opportunity to act on:</h2><h4>Opportunity Name : <span style="color:#ff0000"><xsl:value-of select="ListOfOpportunity/Opportunity/Name"/></span></h4><h3>Here below are the Product Details:</h3><table border="1"><tr bgcolor="#9acd32"><th>Product</th><th>Quantity</th><th>Net Price</th><th>Revenue</th></tr><xsl:for-each select="ListOfOpportunity/Opportunity/ListOfOpportunityProduct/OpportunityProduct"><tr><td><xsl:value-of select="Product"/></td><td><xsl:value-of select="ProductQuantity"/></td><td><xsl:value-of select="ProductPrice"/></td><td><xsl:value-of select="Revenue"/></td></tr></xsl:for-each></table><h3>Here below are the Quote Details:</h3><table border="1"><tr bgcolor="#9acd32"><th>Quote Name</th><th>Revision</th><th>Status</th> </tr><xsl:for-each select="ListOfOpportunity/Opportunity/ListOfQuote2/Quote2"><tr><td><xsl:value-of select="Name2"/></td><td><xsl:value-of select="Revision"/></td><td><xsl:value-of select="Status"/></td></tr></xsl:for-each></table></body></html></xsl:template></xsl:stylesheet>

If you want to learn about XSLT more, then please refer the below link:
http://www.w3schools.com/xsl/

Purging Vs Deleting Workflow Process Instances

This is one of the important information you might be interested in, if you frequently debug a Workflow Process at run-time by increasing the Monitoring Level under "Administration - Business Process -> Workflow Deployment" view.

Whenever you increased the Monitoring Level to "4-Debug", system starts capturing the WF steps details along with the each Process Property at each step, to give a better picture of what has exactly happened at each step and it is very helpful for debug purpose. You can see all Run-time degugging details in "Administration - Business Process -> Workflow Instance Monitor" view.

"Process Instances" gives you all the Workflow Instances run once the Monitoring Level has been increased. It all tells the currently running WF Step.

"Step Instances" captures the details of each step along with its start and end time.

"Process Properties" captures the value of each process property in each WF step.

Though this information is useful but it is a good practice to decreased the log level back to "0-None", once you are done with debugging and also the most important thing you should do is "Purge" all the Workflow Process Instances. Navigate to "Administration Business Process -> Workflow Instance Monitor -> Process Instances", query for the workflow process and click "Purge".

Now, why I am saying this last step of purging these records as "very important"?

Let me tell me what actually happened when I was debugging one of the workflow issue. I increased the monitoring level to 4 for debugging purpose and that workflow was having around 30 workflow steps and around 50 process properties. Additionally, this workflow runs on the child activities (average number around 50) of the Service Request. So you try calculate the number of process property instances record (in S_WFA_STPRP_LOG), system will create in a single workflow run = 30 x 50 x 50 = 75000. Big number isn't it?? So if I debug this workflow few number of times, the number of records will be really huge. But remember, as far as you are purging the records after debugging finishes, then no issues, but if you don't then these records will pile up and some day your database size will run short out of physical space.
So what actually happened was, I made few changes in the workflow and deployed again. Went to "Administration Business Process -> Workflow Deployment" and queried the workflow process and hit "Activate". In the below "child items" applet, system creates a new version of the workflow process with Deployment Status = Active and the older record becomes gets its status = Inactive. So I thought this record is Inactive, let me delete this old instance. I did that few number of times and never realizes that it will just delete this record from "S_WFA_DPLOY_DEF" table and its corresponding child records in "S_WFA_STPRP_LOG" table will keep sitting there. And there is no way you can "Purge" these records from the UI using "Purge" button because the parent record has been deleted earlier.

So it end up having millions of records in this table without parent record and later we realized the database is running short of physical memory and when I checked for the tables in the database which all having huge number of records, we found "S_WFA_STPRP_LOG" table was leading the race. I did the clean-up of the child records via running some SQLs in the database by finding the orphan records in "S_WFA_STPRP_LOG" and learned the lesson using "Purge" button after completing the debugging.

Hope this will also help you in future.

Debugging Siebel eMail Response !!

In our Siebel application, we are using OOB functionality for creating Service Requests via emails, and yes I think you guessed it right we are using Siebel eMail Response workflows which are available in Siebel Tools and you just need to configure them as per your need and these works really well.

(For people who are new to this subject, to find these workflows you need to query in Siebel tools as "eMail Response*", and if you want to learn configure these, just follow the simple steps given in Communications Server Administration Guide)

I really like this OOB feature of Siebel as it works like a magic: user sends an email to Siebel email box whichever you have configured, Response Group keeps monitoring that and whenever see a new email just picks it up, delete it from the email box and invoke the Siebel Workflow. Now from here you can do anything what any workflow in Siebel is capable of doing, design your workflow as per the requirement and you are done.

Pretty simple isn't it, but sometimes it tough to debug it if you land-up in some issue here. I was working on the similar kind of requirement where everything seems working fine but the only problem was: "Response Group was not able to pick the email from Siebel email box".

Response Group only job is to just pick the email and create a MIME format file in "<_siebsrvr>/bin/incoming" folder and passes it as an input argument to eMail Response workflow, but since Response Group was not able to pick the email, so I thought of confirming whether it is reaching to the Siebel emailbox or not, so I logged into webmail client and found all emails keep lying there only.

Since I was able to see all the emails and I have also verified the username/password being used for the email profile in Siebel was correct, that means there is some problem with the POP3 setting of the emailbox. So to check it what you can do is :

a) Get the POP3 server name / username / password for the emailbox which is being monitored by reponse group. (You can find it in "Administration - Communications -> Communications Drivers and Profiles" view by querying for the communication drivers as "Internet SMTP/POP3 Server" and check the name in "Profile Parameter overrides" applet).

b) Click Start -> Run -> type "telnet <_servername> pop3", hit enter.

c) In Telnet window, type "USER <_username>" (without quotes)
if you see +OK, that means username is correct.

d) Type "PASS <_password>" (without quotes)
if you see +OK, that means password is correct.

But I recieved an error message saying "Unknown username or bad password"

So this is something we can't control from Siebel, I checked with the Server administration team who handles all the email servers and they fixed the issue for POP3 settings on the email box and tried the above steps again and this time no error.
[Server admin people really likes to resolve the issue when you go to them with the exact root cause ;) ]

One more reason I can think of for such a behaviour when you have not clicked on "Submit Response Group Changes" for the Response group monitoring the emailbox.

.

How to call "Asynchronous Server Requests" business Service?

Sometimes there is a requirement we need to run few processes that should not stop the user on the screen to go further and do next steps when Siebel is processing something in the background. That is the place when Asychronous processes come into the picture and the solution that Siebel provides for these kind of scenarios is to give a call to "Asynchronous Server Requests" business service.

There are only two ways (that I know my past experience, please add if anyone know more) by which you can call "Asychronous Server Requests" Business Service :

a) Via e-Script : easy way to do that and most people know this.
b) Via Workflow : this is bit tricky

Lets see each one of them in detail. Taken an assumption that you need to invoke a workflow (asynchronously). Assume the workflow name is "Send Email Opportunity Sales Rep", which just sends an email to the Sales Person on the Opportunity and the Input Agrument to the workflow is : "OpptyId" (1-XR45)

Via e-Script :
Here is the piece of code that you can to achieve the above requirement :

var svc = TheApplication().GetService("Asynchronous Server Requests")
var input = TheApplication().NewPropertySet();
var child = TheApplication().NewPropertySet();

var output = TheApplication().NewPropertySet();
input.SetProperty("Component", "WfProcMgr");

child.SetProperty("ProcessName", "Send Email Opportunity Sales Rep");

child.SetProperty("OpptyId", "1-XR45");

input.AddChild(child);

svc.InvokeMethod("SubmitRequest", input, output);

very simple, isn't it. We just need to make sure that the Input Argument of the calling Workflow (Send Email Opportunity Sales Rep) should be the properties of the Child Property Set.

Via Workflow :
Here is the example below in which I have used this and you can accomodate the below two steps in any of the workflow you are using :

Process Properties :

Name : Inputs

Type : Hierarchy

Step1: Set Input Arguments

Business Service : Workflow Utilities

Business Service Method : echo

Step2: Call Asynchronous Service
Business Service : Asynchronous Server Requests
Business Service Method : SubmitRequest

Thats it, you are done. Just to add it here, I tried doing the same stuff with the help of runtime events but it is limitation there and we cannot do that.

.

How to Pass arguments between Workflow & Customize Business Service?

Generally what happens is whenever we create any Customize Business Service, we rarely create "Methods" for it under "Siebel Tools -> Object Explorer-> Business Service -> Business Service Method". What we do is we directly start coding in "Service_PreInvokeMethod" like :
Today I am going to tell you how we can pass arguments of type "String" and "Hierarchy" in the call to Customized Business Service (which don't have any methods specified in "Business Service Method" also don't have any Input/Output arguments specified). If you have worked on the similar requirement earlier, you might be knowing the trick here but for the new people this might be useful.

Lets take the "String" arguments first :

Assuming a requirement to create a workflow where we need to call a customized business service which contains the complex logic and return back the Service Request's status. Please cosider this a requirement for an example here.

Input to Customized Business Service : Service Request Number
Output from Customized Business Service : Status

Here is the Workflow :

So, this seems very simple, right, whatever the "property name" I am setting in the Business Service, the same name should be used in the "Output Argument" of the step.

Lets see what extra need to do in case you are passing a Hierarchy as Input/Output arguments.

Workflow Requirement : 1. Query via EAI Siebel Adapter to get the SiebelMessage for Service Request Number.
2. Pass the Siebel Message as Input Argument to Customized Business Service to update something in it.
3. Get the updated Siebel Message as Output from Customized Business Service.
4. Update the Service Request via EAI Siebel Adapter.

Here is the workflow :

I think you need to try it out at your end to actually understand the trick here. Check it out !!

.

Debugging Siebel Workflow Process at Runtime

Sometimes it happens that you perform some operation, which needs to trigger a workflow process (synchronous / asynchronous) and you realised that it has not performed as per the expectation and want to see what exactly it has done. Workflow is a collection of some steps which gets executed sequentially, so you might need to track what it has done in each step and in which step some problem has occured.

Siebel provides a way to debug a already deployed workflow at the runtime and its very easy as you can do it in web client itself. What you need to do is :

1. Navigate to "Administration-Business Process -> Workflow Deployment -> Active Workflow Processes" view.

2. Query for the Workflow Process in the bottom applet.

3. Change the "Monitoring - Level" for the workflow process to "4 - Debug".

4. Now go and perform the same action again which will trigger this workflow.

5. If it again errored out or not performed as per the expectation and you want to track it execution step by step, navigate to : "Administration-Business Process -> Workflow Instance Monitor" view.

6. Query for the Workflow Process in upper applet. System will show all the instances executed for that workflow in the bottom applet. Sort the instances via "Start Date" descending.

7. Navigate to "Step Instances" view.

8. Now you can see, what all process properties were in each step of the workflow and make out what went wrong.

Isn't easy to have any workflow running in Debug mode at the runtime?

Hope this helps.

.

Scheduling Automatic Export in Siebel

List applets provide the OOB export functionality which is very useful sometimes when Managers want to do some analysis depending on various combinations and permutations on the live data very quickly. But if you need to do the same task on the daily basis, you will think, can't I get the export automatically from Siebel via email instead of I go to the list applet and take the export. The same happened with my client too. He want to automate this export process that he generally does on the daily basis from All Service Requests List Applet.

Lets see how this is achievable :

On the very high level, the solution is to :

1. Create a Workflow which can take the Export and send it in an email to the user.
2. Create a RCR (Repeating Component Request) which will get executed on the daily basis and run a workflow.

Workflow Creation:

Here below are major steps that used in Workflow to acheive the solution.

• Query Service Request
  Business Service Name = Import/Export
  Business Service Method = Export
  Input arguments for this step are as follows :
  
  ==> FileName : "<_filename.xls>" (for eg: /temp/export.xls). Please make sure you should provide the extension as .xls
  
  ==> FileType: XML
  
  ==> IntObjectName : Service Request (this is the IO that I have created which has only one Integration Component i.e. Service Request). You can also use the OOB available IO for this purpose, if fits into the requirement.
  
  
• Send Email
  Business Service Name : Outbound Communications Manager
  Business Service Method Name : SendMessage
  Input arguments for this step are as follows :
  
  ==> MsgToList : "<_youremailaddress>"
  
  ==> CommProfile : "<_communicationprofilename>". if you want to know, how to setup a Communication Profile, please refer to :
  http://siebelmantra.blogspot.com/2009/04/how-to-setup-communication-profile-for.html
  
  ==> MsgSubject : Export from Siebel
  
  ==> MsgBody : This is the test export from Siebel
  
  ==> AttachFileList : <_filename.xls>. (for eg: /temp/export.xls).

Workflow is ready, Publish and Activate it and simulate it on the Server to check if running fine.

RCR (Repeating Component Request) Creation :

Here below are the steps for creating the RCR job and let the Workflow run on the daily basis.

• Navigate to "Administration-Management -> Jobs" view.
• Click on "New" and select "Component/Job" = "Workflow Process Manager".
• Under Repeating Info section, select the following :
  
  
• Under Job Parameters applet, create a new select with the following info :
  Workflow Process Name : <_name>
• Click on "Submit Job"

And you are done with the complete process. Siebel will automatically take the export and send you the file on the daily basis.

Enjoy !!!!