Building a BI Developer's SuperView

Another limitation I find irritating when it comes to building BI templates is how basic the sample file generator is. My main beef is that it just takes the first 10 records in the Integration Object and spits them out. If you have a complicated IO with child ICs, it is possible, and even likely that those first ten records do not have the child detail records you need to test your report output. There are some ways around this, like hard coding a search spec on the BC against a thick client partial compile to generate a file with data you want, but that seems so inelegant. My other tick regarding this feature is that the report developer once again either needs to have a Siebel thick client or access to the Siebel Server file system to actually get the xml file produced. It seems like the whole point of all the BI Administration views is to avoid having to go to the file system. What to do...

Caveat Emptor. Configuration steps below are to give you an idea. I am posting this after I finished to highlight what I recall as the important pieces so not every step is included. You will need to create the new custom table CX_TMPL (or use another), create all links, applets, view objects, make BO/Screen changes and deploy them.

First I build a view with the same IO BC based applet as the vanilla view on top, and child applets for both attachments and a new object which is essentially a search spec. First the attachment bc. This is a new BC which you can copy from an existing attachment BC and change the names around. Here is mine, called 'Sample IO Attachment' based on S_FILE_ATT. Use the field name prefix 'Sample' instead of which ever prefix is used on the BC you are copying (Be sure to set the User Property DefaultPrefix to 'Sample' too):

Name	Join	Column	Force Active	Predefault Value	Text Length	Type
IO Id		PAR_ROW_ID	Y	Parent: 'Repository Integration Object.Id'	15	DTYPE_ID
Parent Key		X_PARENT_KEY		Parent: 'Repository Integration Object.Name'	100	DTYPE_TEXT

The Search Spec applet is based on a custom BC, 'Report IO Sample File Template', based on the new table, CX_TMPL (I use this table for other things too so I type spec each record):

Name	Join	Column	Force Active	Predefault Value	Text Length	Type
Name		NAME		Field: "Id"	100	DTYPE_TEXT
Parent Id	S_INT_OBJ	ROW_ID	Y	Parent: "Repository Integration Object.Id"	15	DTYPE_ID
Parent Name		PARENT_FLD		Parent: "Repository Integration Object.Name"	50	DTYPE_TEXT
Search Specification		CONSTRAINT	Y		250	DTYPE_TEXT
Type		TYPE		SAMPLE_IO_CONSTRAINT	30	DTYPE_TEXT
Number of Records		LN_NUM		10		DTYPE_INTEGER

The join, S_INT_OBJ, is based on the specification of Parent Name = NAME. Using name instead of Id allows the search specs to remain visible after repository moves.

You will also need the following Named Method User Property:

"GenerateConstrainedData", "INVOKESVC", "Report IO Sample File Template", "Workflow Process Manager", "RunProcess", "'ProcessName'", "'Export Sample IO To File'", "SearchConstraint", "[Search Specification]", "'IOName'", "[Parent Name]", "Path", "'..\XMLP\Data'", "Object Id", "[Parent Id]", "PageSize", "[Number of Records]"

This user property is to activate the button you will need to place on the applet based on this BC. On that applet (based on class CSSSWEFrameListBase), add a button which invokes the method 'GenerateConstrainedData'. No additional script should be needed there.

Create a Service Flow Workflow Process called 'Export Sample IO To File'


Here are the Process Properties:

Name	In/Out	Data Type
FileName	In	String
IOName	In	String
PageSize	In	String
Path	In	String
SearchConstraint	In	String
SiebelMessage	None	Hierarchy
ViewMode	In	String

The first 'Echo' step is a Business Service based on Workflow Utilities, Echo method. This step sets up all the variables used later in the process. Here are the arguments:

I/O	Argument	Type	Value/Property Name
Input	IOName	Process Property	IOName
Input	PageSize	Process Property	PageSize
Input	Path	Process Property	Path
Input	SearchConstraint	Process Property	SearchConstraint
Input	ViewMode	Process Property	ViewMode
Output	FileName	Expression	IIF([&FileName] is not null, [&FileName], [&IOName])

The next 'Export IO' step is a Business Service based on EAI Siebel Adapter, QueryPage method. This step queries the integration object. Here are the arguments:

I/O	Argument	Type	Value/Property Name
Input	OutputIntObjectName	Process Property	IOName
Input	PageSize	Process Property	PageSize
Input	SearchSpec	Process Property	SearchConstraint
Input	ViewMode	Process Property	ViewMode
Output	SiebelMessage	Output Argument	SiebelMessage

The next 'Write to File' step is the Business Service, EAI XML Write to File, WriteEAIMsg method. This step writes the property set out as an XML document to the file system. Here are the arguments:

I/O	Argument	Type	Value/Property Name
Input	FileName	Expression	[&Path]+"\"+[&Process Instance Id]+"_"+[&FileName]+".xml"
Input	SiebelMessage	Process Property	SiebelMessage

The final 'Attach' step is another Business Service, this one custom. The basic logic here is to add an Attachment to the file system which is first described in Oracle document 477534.1 (I have made some improvements which I will perhaps discuss another day). Here are the arguments:

I/O	Argument	Type	Value/Property Name
Input	AttBusinessComponent	Literal	Sample IO Attachment
Input	AttachmentFieldName	Literal	SampleFileName
Input	BusinessObject	Literal	Repository Integration Object
Input	File	Expression	[&Path]+"\"+[&Process Instance Id]+"_"+[&FileName]+".xml"
Input	ObjectId	Process Property	Object Id
Input	PrimaryBusinessComponent	Literal	Repository Integration Object

A Basic Interface - Web Service Workflow

Just about every interface consists of two basic components: the integration object(s) and the workflow or business service. I will demonstrate a workflow approach which will give you more opportunity to customize down the road.

It is here that we begin to differentiate the integration by the communication mechanism. Because I am designating this integration as a Web Service, that will drive the type of data this workflow will expect as an input and output. The workflow I build will eventually be exposed as a WSDL to be consumed by an external program. That WSDL should have the definition of the message it is expecting, in this case, the XSD, or definition of the Integration Object we just built. How we accomplish this is to set the Input Process Property to a Data Type of 'Integration Object' and to actually specify the integration object we built, in the Integration Object attribute of the process property.


You can also see my place holder for the SR Number that I want to return to the external system in the response message. The 'IncomingXML' property is already in the format needed to be passed to the EAI Siebel Adapter, so there is no conversion necessary. And we are assuming that the data being passed is exactly as it should be applied. You will create the following steps which I will explain (other than Start and End which are self explanatory):
The 'Upsert SR' is a Business Service calling 'EAI Siebel Adapter'. Now here is the another design decision to be made. Each of the available methods differentiate exactly how the data should be applied. But there are two broad determinations. If we were to use the Execute method, then the 'operation' element which exists in each component of the IO would be used to determine how the data should be applied. This gives more control the calling system (or a data map which I will discuss later). The other set of methods essentially comprise a One Size Fit All to applying all the data uniformly. I will use the latter approach here and set the method to 'Upsert'. There is only one component in my IO, so if it exists, it will be updated, otherwise it will be inserted. The input arguments for this step are the IncomingXML message from the external system and a parameter telling the EAI Siebel Adapter to create the Status Object.

There is one Output Argument. We no longer care about the input message at this point because it will have been applied so we just overwrite it with the return, which in this case will be the status key.
The last step in the WF is another Business Service step calling 'PRM ANI Utility Service', 'GetProperty' method. This business service has a plethora of useful methods for manipulating property sets. This particular method will extract the value of a field from an integration object instance. Here are the inputs:
The output is to set the process property 'SRNumber' with the Output Argument, 'Property Value'. When the return message is sent back to the calling system, this property will exist with the generated SR Number.

Simulating/Troubleshooting this WF from within tools is difficult as built so I sometimes add a bypass step off the start branch to read the integration object from a file. I may talk about this later but want to keep this post pretty straightforward. So for now, this workflow can just be deployed, checked in and activated.

How to call Workflow - Custom Remote

My previous posts discussed some of the mechanisms to call a workflow process along with their pros and cons. I alluded to how the mode that was desired would determine which business service to call. Workflow Process Manager is the vanilla business process which allows for executing a workflow process in Local Synchronous mode. Siebel provides another business service, Server Requests, which is capable of starting a task in a different component, hence running the process remotely. Unfortuneately, the necessary inputs to this business service must be passed in a child property set, so this business service cannot be called directly from the action of an action set using the business service context attribute. What needs to be done is to is to call a custom shell business service which fills a child property set with the correct attributes, then calls the vanilla Server Request business service.

Let's see how this is done. First of all, a new custom business service needs to be created:

Now create a new custom method for this service:

Finally, create the following method arguments for this new method:

Ok. Now for the script. The script I will about to specify has several features:

• Calls the Server Requests business service which runs a workflow process in the Workflow Process Manager server somponent in its own thread
• Input Properties to the Server Requests business service cannot be passed through the business service context attribute of an Action, as Siebel expects these properties as a child property set.
• Can be called from a Run Time Event-Action by setting all properties as Profile Attributes
• Can be called from a business service or workflow process by setting all properties directly as Input properties
• Takes input properties, either from from profile attributes or from input property set, and passes them as custom input properties to a workflow process.
• Profile Attribute name will be "PassThrough1", for instance, and the profile attribute value must be in the format "", ""
• Can optionally specify a specific application server to run on, otherwise will allow the load balancer to assign the server
• By default, will run in Remote Synchronous mode if user is connected, otherwise will run Remote Asynchronously.
• Can optionally be set to be run as explicitly Remote Asynchronously

This is written in eScript and there are plenty of different ways to go about this, but this is a rough guide (actually, not so rough):

How to call Workflow - Custom

An alternative to the "Managed" runtime events, meaning that the process of activating workflow process creates and updates runtime events and action sets, is to create your own runtime events and action sets. This allows you to create complex sequences of workflow process calls, perhaps setting several profile attributes that are needed in the workflow, calling different versions a workflow process based on mutually exclusive conditional expressions, and calling workflow in different calling modes. With great power comes great responsibility. Walking away from the simple management the activation process provides gives you a lot of flexibility but it also makes your system more complicated and deployment a bit trickier. I think I have said deployment is trick either way now, which when you are talking about complicated processes is probably true regardless. I tend to think the custom route is easier to understand because you control all the steps and the names are more logical because they are your names.

So let me start by defining what I mean by custom managed events. You can achieve the same affect as the managed architecture by creating your own runtime event in the GUI (Administration - Runtime Events) with the same parameters used in the tools workflow pallet, start branch step attributes.

Then you create a custom Action Set with as many custom Actions as necessary. Conditional expressions can be used to prevent the instantiation of a workflow process manager component unnecessarily.The step that needs to actually calls the workflow will have an Action Type of 'BusService'. The Business Service Name will depend on what mode you want the workflow to run in. To simply replicate what the managed process does, just set the Business Process Name to 'Workflow Process Manager', the Method to 'RunProcess', and the Context to "ProcessName", "workflow name" where workflow name is. . . you know. This is a Name, Value pair format for properties accepted by the business service.
It is important to recognize that dynamic process properties cannot be passed to the WF through the business service context. This is because process properties are expected as a child property set. Plus the business service context cannot resolve expressions. If you need to pass dynamic process properties to the workflow, you have two options. You can either set a profile attribute that can be referenced in the workflow or you can create a shell service which I will get into in my next post.

How to call Workflow - Managed

Workflow can be called a variety of ways, with a variety of advantages for each. This will be the first post in a series about the pros and cons of these various mechanisms, along with a tool to assist with some of these approaches.

The most basic, declarative, out of the box way to call workflow is through a run time event managed by the start step of the Workflow process. Let’s take a basic workflow that is meant to call a custom business service when the Account is updated. If you select the branch from the start step, the WF Step Branch applet appears beneath the pallet.

The Event attributes specify a Runtime Event and Action Set that will be created in the GUI when the workflow is deployed and activated. The Action Set has the naming convention Workflow_Row_ID where Row_ID is that of the Action Set record. The Action Set has a single action whose name is Workflow_Row_ID_Row_ID where the first Row_ID is that of the deployed workflow process (can be found in the Active Workflow Processes applet of the Workflow Deployment view). I am not really sure what the second is.

A workflow process called in this way is considered to be running in Local Synchronous mode. The Local refers to the fact that is executing from the same thread that is was called from. So if a user action in the GUI triggers the run time event, then the workflow would be executed within the Sales Object Manager component (or whichever); if the an EAI update were to trigger the runtime event, the workflow would be executed in the EAI Object Manager. Therefore turning up event logging to troubleshoot a workflow called in this manner would require doing so to the Object Manager. The Synchronous part refers to the fact the user session will wait until the workflow has completed execution before control is returned to the user.

If instead of a business service, you had Siebel operation steps in the workflow, it is important to realize that any queries executed would take the most restrictive visibility of the object being queried. In the workflow above which is based on an update to the Account BC, adding a Siebel Operation Query on the Account BC would automatically apply Sales Team visibility to the query. Where this sometimes has an impact is if Assignment Manager runs synchronously between the time the triggering record is committed and when the workflow executes. In that case, the account may no longer be visible to the person who updated the record.

Some of the complexities in managing workflow this way are when you need to do a series of things in a particular order. Finding Workflow with this naming convention can be confusing, but in theory, knowing the naming convention means you can identify the action set you need, and you could then add your own custom actions to that action set, say to set some profile attributes prior to calling the workflow. Or you can add a conditional expression to the action. The hard part is when you need to deploy a new version of that workflow. The deployment and activation process which manages the naming convention can corrupt your custom actions, requiring you to set them up all over again. Deployment in general can get tricky with this approach because the Row Ids are used in the names and Row Ids between environments will differ for the same process. This means that you need to deploy and activate workflows in each environment to generate the runtime events and action sets, but if you need to migrate runtime events and action sets for other reasons, either for personalization or other custom development, you will need to be careful that your workflow managed runtime events from your source environment to not migrate and hence become duplicated in the target environment.

UPDATE: I recalled another serious limitation of this approach.  Workflow called in Local Synchronous mode will only execute if the active business object at the time the runtime event is triggered matches the business object of the workflow.  This implies that if you have a runtime event on the write of an Activity, you would need multiple workflows, one for each business object the Action BC appears in that needs to trigger the workflow.  If you have determined this is still the best approach to use, I suggest a series of shell workflow processes that call a single primary workflow as a subprocess where the primary is based on the main Activity BO, and the shells are based on the various other BOs, all having a single step.