tech note 581

8/6/2019 Tech Note 581

http://slidepdf.com/reader/full/tech-note-581 1/56

Siebel 7.7 Workf l ow

of 56

8/6/2019 Tech Note 581


Table of Contents

Introduction...................................................................................................................................... 3 What is Siebel Workflow?................................................................................................................ 3 Workflow Runtime Architecture ....................................................................................................... 4 Development and Deployment Lifecycle ......................................................................................... 5

Step 1: Analyze Requirements – Rules and Processes to be Automated ................................. 5 Step 2: Define Processes in Siebel Workflow............................................................................. 6

Workflow Basics ....................................................................................................................... 6 Events – Invoking Siebel Workflow Processes ........................................................................ 7 A Word on Workflow Policies ................................................................................................... 8 Business Logic and Decision Rules ......................................................................................... 9 Decision Rules: Decision Step Details .................................................................................. 10 Actions.................................................................................................................................... 11 Actions: Business Service Step............................................................................................. 11 Actions: Siebel Operation Step ............................................................................................. 13 Actions: Wait Step ................................................................................................................. 13 A Word about Process Properties.......................................................................................... 13 Developing Workflows in Siebel Tools ................................................................................... 14

Step 3: Identify and Build Exception Handling .......................................................................... 15 Step 4: Test and Simulate Workflow Processes....................................................................... 15 Simulator ................................................................................................................................ 16 Using Business Service Simulator ......................................................................................... 16 Event Logs.............................................................................................................................. 16

Step 5: Migrate to Production ................................................................................................... 16 Step 6: Monitor Processes........................................................................................................ 18

Externalize parameters .......................................................................................................... 18 Troubleshooting of workflows in production environment ...................................................... 18 Communicating workflow errors to Siebel Technical Services professionals ........................ 19

Troubleshooting – Common Workflow Errors ............................................................................... 19 Examples....................................................................................................................................... 21

Example 1: Attach Activity Plan to an Oppty - Test with Simulator and Runtime Client........... 21 Step 1: Configure a New Workflow ....................................................................................... 21 Step 2: Test the Workflow Using the Simulator..................................................................... 27 Step 3: Call the Workflow from the UI using a Runtime Event.............................................. 32 Step 4: Deploy and Activate the Workflow Process.............................................................. 34 Step 5: Test the Workflow using the Runtime Client............................................................. 38

Example 2: Creating Workflow Process Triggered by Runtime Event ..................................... 39 Example 3: Creating a Service Mode Workflow ....................................................................... 44 Example 4: Runtime Event Workflow with User Interact Step to Navigate User to a View...... 51 Example 5: Externalize parameters to be used by workflow.................................................... 53

Overview................................................................................................................................. 53 Design .................................................................................................................................... 54

of 56

8/6/2019 Tech Note 581


IntroductionSiebel Workflow is a robust technology that allows companies to enable process automationwithin Siebel applications. Because the automation of typical business processes can becomplex, documentation that further explains how Siebel Workflow can be used and providesexamples, is useful. The intent of this document is to augment the Siebel Business ProcessAdministration Guide with additional information and practical examples. The target audience forthis document IT Project Managers, IT developers with Workflow skills ranging from novice toadvanced. The information in the document ranges from very basic and simple concepts to moreadvanced topics.

What is Siebel Workflow?Siebel Workflow orchestrates other Siebel process automation technologies. Workflowprocesses graphically sequence a series of automation steps that support a process, and specifyinputs and outputs for individual steps and for the process as a whole.

Figure 1. Siebel Automation Technologies

WWoorrkkffllooww PPoolliicciieess

WWoorrkkffllooww PPrroocceesssseess

Technologies that enable business process computing in Siebel are:

• Assignment Manager – Expresses rules to assign records to people, enables assignmentbased on skills, workload, availability, etc and supports ownership transitions within aprocess.

• SmartScript – Guides users through data entry tasks, and is effective for call scriptingand includes basic support for transaction level commits.

• Activity Template – Contains a pre-defined series of to-do steps and is effective forhandling asynchronous/offline tasks.

• Workflow Policies – Generates events based on database operations and is effective forperforming simple actions such as sending email, creating an activity or assignment.

• State Models – Restricts transition of record status based on current value and position ofthe user. Also can enforce directional progression of status, for example soOpportunities move forward but not backward through a pipeline.

AAssssiiggnnmmeenntt MMaannaaggeerr

SSmmaarrttSSccrriipptt

SSttaattee MMooddeell AAccttiivviittyy

TTeemmppllaattee

of 56

8/6/2019 Tech Note 581


Each of these technologies delivers specific functionality. Workflow process acts as theorchestrator of many of the services performed by each of these technologies. Thesetechnologies are part of Siebel’s infrastructure and together they enable business processcomputing in Siebel. A workflow process acts as the orchestrator either invoking each of thetechnologies directly, or interacting through Siebel’s robust event model and is the key technologybehind building business processes in Siebel. The focus of this document is on Workflow.

In Siebel 7.7, Siebel Workflow has been moved from the Siebel Client to Siebel Tools. HostingSiebel Workflow in Siebel Tools would provide an integrated development environment toconfigure Siebel objects including workflow. An integrated development environment allows atop-down development framework for building business logic that start with a process and thenprovide pluggable services and data objects that make the process executable.

Workflow Runtime ArchitectureThe Workflow runtime architecture is based on the Siebel Object Manager layer and the serverinfrastructure layer of the Siebel applications architecture. The runtime environment is availableboth as a business service and as a server component. Siebel Business Process Designer hasfour types of workflow processes that characterize runtime behavior. The processing type is set in

the Workflow Processes list editor of Siebel Tools, using the Workflow Mode field. The workflowprocess types are as follows:

• 7.0 Flow. A 7.0 workflow process provides backward compatibility for existingSiebel 7 (pre-7.7) workflows.

• Long Running Flow. A long-running workflow process is a persistent workflowthat can last for hours, days, or months.

• Interactive Flow. An interactive workflow process navigates the user acrossSiebel views.

• Service Flow. A service workflow process executes a set of operations uponevent invocation.

The runtime architecture supports three invocation modes for invoking and resuming workflowprocesses: Local Synchronous, Remote Synchronous, and Remote Asynchronous. Figure 2below shows the runtime architecture:

Figure 2. Workflow Runtime Architecture

of 56

8/6/2019 Tech Note 581


Development and Deployment LifecycleFigure 3, below depicts the development and deployment lifecycle for a Workflow. Note, this isshown as a linear flow, however the typical development process is iterative. Each of these stepswill be discussed in detail in the following sections.

Figure 3. Development and Deployment Lifecycle

Step 1: Analyze Requirements – Rules and Processes to be

Automated An implementation project team will typically spend a fair amount of time on requirementsanalysis. It is not unusual for this to be about 30% of the of the total implementation time. Abusiness analyst will define processes he wants automated in Siebel. A developer would reviewthese processes and when making design decisions on how to implement these, he would lookfor areas of:

• Repetitive, manual processing

• Timely processing of an event

• Escalations and notifications,

as candidates to be implemented in Siebel workflow. When making implementation decisions, a

developer should consider the follow options for automating processes. Some major tradeoffsare listed in Table 1 below.

Table 1. Siebel Workflow Process Framework versus Other Siebel Mechanisms

Framework Key Advantages Limitations

1. Analyze Business

Requirements – Rulesand Processes to

be Automated

2. Define Processes

in Siebel Workflow

3. Identify and Build

Exception Handling

4. Validate and

Simulate Process

5. Migrate to

Production

6. Monitor Process

1. Analyze Business

Requirements – Rulesand Processes to

be Automated

2. Define Processes

in Siebel Workflow

3. Identify and Build

Exception Handling

4. Validate and

Simulate Process

5. Migrate to

Production

6. Monitor Process

of 56

8/6/2019 Tech Note 581


WorkflowProcess

• Visual representation of businesslogic is relatively to understandand maintain

• Remote synchronous andasynchronous execution enables

broad horizontal scalability andlong running transactions

Semantics for control of flow not asrich as scripting. Specific limitationsinclude:

• Limited control of flow foriterating through record sets,

etc.

• Limited direct access toobject methods

WorkflowPolicies

• Respond to database eventsregardless of whether they’reinitiated by an OM or non-OMcomponent

• May get higher transactionthroughput on a given set ofhardware for simple transactions

• Changes to policies may requiredatabase downtime to implement

• More difficult to configure that otheralternatives

• Limited range of executable actions

Siebel Script • Familiar to most developers

• Complete set of semantics/ highlyflexible

• Widespread scripting degrades:

o Maintainabilityo Upgradabilityo Performance

Step 2: Define Processes in Siebel Workflow

Workflow BasicsWith Siebel Workflow, the run-time engine manages process flow, application flow and integration

flow. The following basic constructs are available to define your Workflow process:Figure 4. Palette

Start – defines the beginning of a processDecision – defines branching in the workflowBusiness Service – performs custom or pre-built actionsSub-process – calls another processSiebel Operation – updates the Siebel databaseWait – pauses processingUser Interact – navigates to a Siebel viewStop – stops the process and displays a messageEnd – defines the end of a processConnector – defines sequence, can define conditions associated withit

Exception – defines a branch taken outside of the normal flow,when an exception occurs.

The Siebel Workflow User’s Guide provides detailed explanations onhow to implement each of these steps. However, there are some keycomponents that enable runtime execution that will be discussed inmore detail here (see Figure 4):

of 56

8/6/2019 Tech Note 581


• Events – Workflow processes can be invoked from events in the Siebel application orfrom external systems. Events can pass context from the caller, user session, forexample to a workflow using a row-id.

• Rules – The flow control is based on rules. Rules can be based on business componentdata or local variables, known as process properties. Rule expressions are defined usingSiebel Query Language.

•

Actions – Action can perform database record operations or invoke Business Services.Also, an action can cause a pause in the workflow.

• Data is created or updated as the process executes. There are basically three types ofdata a workflow process will operate on, business business component data,processprocess properties, and Siebel Common Object data. You can think of processproperties as local variables that are active during the process. The variables are usedas inputs and outputs to the various steps in a process.

Figure 5. Workflow Building Blocks

ActionsEvents

• DatabaseOperation

• Workflow Policies

• Run-time Events

• Invoke a Service• Siebel ToolsObject Events • Pause a Workflow

Rules

• Workflow Decision Step

• Scripted BusinessServices

• Other Specialized Rule

Events – Invoking Siebel Workflow ProcessesThere are basically three ways to invoke a workflow workflow process, through workflowpoliciesworkflow policies, run-time events, and Siebel Tools object events.

Workflow policies allow you to define policies, or rules that can act as triggers to execute aworkflow process. The basic construct of a policy is a rule. If all the conditions of a rule are true,then an action occurs. Typical usages of a workflow policy are EIM batch, EAI inserts andupdates, manual changes from the user interface, assignment manager assignments and Siebel

remote synchronization.

Table 2. Invoking Workflow

of 56

8/6/2019 Tech Note 581


Type Description When Useful Limitations

WorkflowPolicies

• Trigger based ondatabase changes

• Need to detect andreact to data changesmade outside of theobject managerObject

Manager (OM) – forexample, by SiebelRemote or EIM

• Changes require databasedowntime

• Relatively complex to

configure

RuntimeEvents

• Raised by OM

• Belong to 3 objects:Application, Applet,BusinessComponent

• Configurable fromAdministrativeinterface

• Need to implementbasic entry point for aworkflow or simplecustom action

• Need to avoiddistributing .srf files – e.g., because ofburden on mobileusers

• Can’t directly respond toevent by scripting againstthe event object

• Can be more difficult topass event context tobusiness logic

• Don’t trap data changesmade by non OM

components“Tools”ObjectEvents

• Raised by OM

• Belong to 4 objects:Application, Applet,BusinessComponent,Business Service

• Scriptable fromSiebel Tools

• Need flexibility to writescript directly inresponse to an event

• Need access to anapplet event that’sonly exposed in SiebelTools

• Changes must bedistributed through new .srffile

• Does not trap data changesmade by non OMcomponents

When deciding whether to implement a workflow policy versus a workflow process there are

some additional things you may want to consider. Data coming into the Siebel application via thedata layer, such as EIM and MQ channels, and those that cannot be captured via the businesslayer are typically good candidates for a workflow policy. Some features not supported byworkflow processes like eMail Consolidation, Duration, and Quantity are also candidates forworkflow policies. However, workflow processes provide a better platform for development anddeployment, complex comparison logic, flow management (if, then, else, or case), leveragesbusiness layer logic, can invoke Business Services and pause/stop/error handling capability

A Word on Workflow PoliciesWorkflow Process and Runtime events ensure most events are captured at the business layerlogic level. However there are business scenarios where the Workflow Policy Manager would bethe best alternative. Workflow Policy Manager ensures business logic is captured at the data

layer of Siebel architecture. Some examples of such scenarios would be when bulk data uploadshappen via EIM or Data Quality cleaning happens in the data layer.

The diagram below, Figure 6, displays Workflow Policy architecture.

• When using Workflow Policy, the data layer business policy enforcement is done viadatabase triggers.

• When a particular policy is violated, underlying triggers capture database events intoa Workflow Policy Manager's queuing table (S_ESCL_REQ).

of 56

8/6/2019 Tech Note 581


• Workflow Policy Manager component (Workflow Monitor Agent) polls this table andprocesses requests by taking appropriate actions defined. In some cases, actionsmight be to invoke Workflow Process Manager.

• Workflow Policy Manager provides additional scalability by using an additionalcomponent called Workflow Action Agent that can be executed on a differentapplication server within the Siebel Enterprise.

Figure 6 Workflow Policies

End-user activity or server process

Business Logic and Decision RulesThere are several different ways to implement business rules in a Workflow process. The

following chart shows the major ways and a comparison on when to use them.

Table 3. Business Logic

Type Description When Useful Limitations

WorkflowDecisionStep

• Kind of step in a Workflow thatarbitrates between one ormore alternative branches in aflow

• Each branch out of decisionstep has one or moreconditions – if all evaluate to

TRUE for the branch the flowwill continue down the branch

• Need a simplearticulation ofwhether one ormore alternativeactions in flowshould be taken

• Conditional expressionslack support for somekey operators including:

o ANDo ORo Order of

precedencecontrol (such as

parentheses)

ScriptedBusinessServices

• Script within a businessservice Action step thatevaluates a potentiallycomplex set of inputs andreturns a simplified output thatcan be evaluated by aworkflow decision step

• Workflowdecision stepsemantics notsufficientlyexpressive toencapsulatedecision criteria

• Undermine readabilityand simplicity ofworkflow by hiding logicwithin a service

WorkflowMonitor Agent

ServerRequest Broker

WorkflowProcess Mgr

EIMS_ESCL_REQ

SiebelDatabase

Generatetriggers

Triggers fire

Create triggers

Reads records

of 56

8/6/2019 Tech Note 581


OtherSpecializedRuleFrameworks

• Other rule frameworks thatmay be leveraged directly orindirectly by a workflow

o Personalization Ruleso Assignment Rules

Decision Rules: Decision Step DetailsDecision steps exit with multiple branches. For each branch a conditional statement is evaluated.A conditional statement compares any two of the following:

• process properties,

• business component fields or

• literal values.The terms of comparison include:

• two values are equivalent,

• one value exists among a series of others, for example, child record values, one or allmust match,

• greater than or less than,

• between or not between, and

• null or not null.The Compose Condition Criteria dialog box is shown in Figure 7. This example shows a branchin a workflow where the branch would be followed if the Severity field from a Service Requestmatched the value “1-Critical”.

Figure 7. Decision Criteria

of 56

8/6/2019 Tech Note 581


ActionsThere are several ways to affect actions in a workflow. In other words, data is taken as an input,a transformation takes place and data is produced as output. The Table 4 below shows the majorways to cause a transformation with some explanation of how to make design decision on how touse them.

Table 4. Actions in Siebel WorkflowType Description When Useful Limitations

BusinessService Step

• Workflow Stepthat invokes amethod ofbusiness service

• Business servicemay be a pre-built Siebelservice or acustomer defined

(scripted)business service

• Need to executepotentiallycomplex, butreusable set oflogic

• Creating and destroyingbusiness services can beexpensive – overhead can bereduced through caching

• Incorporating too much logic witha business service may limit it’sreusability and the transparencyof the workflow

DatabaseOperation

• Workflow stepthat performsInserts, Updatesand Queriesagainst Siebelbusinesscomponents

• Need to executesimple recordoperations withinthe workflow

• Possible to update multiplerecords based on a searchspecification, but it’s not possibleto retrieve and iterate through aset of records such thatsubsequent workflow actions canexecute for each record

Wait • Puts the workflowinto a holdingpattern until areleasing event is

fired or a timeoutoccurs

• Useful to supporttime-basedescalations orlong running

flows that maylast for days orweeks – forexample, waitingfor a customerresponse

• Releasing event must betriggered through the OM

Actions: Business Service StepBusiness Service steps execute predefined or custom methods. Typical predefined businessservices used include Assignment Manager requests, Notification through the CommunicationsServer, server requests and integration requests (EAI). Custom Business Services can be written

in Siebel VB or eScript. When defining a Business Service step you must specify the businessservice, the business service method, input arguments (pass in Process Property, BusCompdata, or literal value) and output arguments.

Some commonly used Business Service in Workflow processes include:

1. FINS Data Transfer Utilities

• Description: Allows you to transfer data from source BC to a destination BC withoutscript.

• Available Methods:

of 56

8/6/2019 Tech Note 581


• DataTransfer

• GetActiveViewProp

• QueueMethod

• TryMockMethod.

2. FINS Validator

•

Description: Validate data based on predefined rules. It is developed throughApplication Administration and not script. Also, supports custom messages.


• Validate

3. FINS Dynamic UI Service

• Description: Allows creating and rendering of read-only views with a single read-onlyapplet based on user input. Administered through admin views and not script.


• AddRow

• DeleteRow

• SetViewName

4. Outbound Communications Manager• Description: Automates sending notifications via fax and emails to contacts and

employees.


• CreateRequest

• SendMessage

• SendSmtpMessage

• SubmitRequest

5. Synchronous Assignment Manager Requests

• Description: Automates assigning objects by using Assignment Manager rules.


• Assign

6. Server Requests

• Description: Allows sending of generic requests to the request broker. It can send it inthree different modes: asynchronous, synchronous, or schedule mode. (Example, call aworkflow but need to be asynchronous request)


• SubmitRequest

• CancelRequest

7. Report Business Service

• Description: Automates sending, scheduling, printing, saving, emailing reports. Also,automates administrative tasks such as synching new users.


• ExecuteReport• DelOne

• DownloadReport

• GrantRoleAccess2Report

• GrantUserAccess2Report

• PrintReport

• RunAndEmailReport

• ScheduleReport

• SyncOne

of 56

8/6/2019 Tech Note 581


Actions: Siebel Operation StepSiebel Operation steps allow you to perform database operations of Insert, Update and Query.These steps are performed on business components. Once you have defined the Operationstep, you can use the Fields child object to define any field values for the step. Also, for an

Update you can use the Search Specification child object to define the records you want toupdate.

Examples of Operations steps include creating an Activity record when a new SR is opened orupdating a comment field if an SR has been open too long.

Actions: Wait StepWait steps allow you to suspend process execution for a specified period of time or until a specificevent occurs.

The example below shows how you can define a timeout based on time defined as literal valuesin input arguments.

Figure 8. Wait Step

A Word about Process PropertiesProcess properties are used as input and output arguments for the entire process. Processproperties are used to store values that a workflow process retrieves from the database orderives before or during processing. Decision branches can use the values in a process propertyand pass properties as step arguments. When a workflow process completes, the final results ofthe process properties are available as output arguments. Process property values can be usedin expressions.

With every workflow there is a set of predefined process properties that are automaticallygenerated when you define the workflow. These are:

• Error Code: Populated by a step should an error occur

• Error Message: Populated by a step should an error occur

• Object Id: Row ID of the record against which the process is invoked

• Process Instance ID: Unique number assigned to the currently running instanceof the process

• Siebel Operation Object ID: Row ID of the record inserted by the SiebelOperation step

As an example for using process properties, you could define three new process properties for aworkflow. These properties are of type string shown below. They have values “Welcome”, “to”,and “Siebel”.

of 56

8/6/2019 Tech Note 581


Figure 9. Process Properties

You can create a fourth process property, ProcessProperty4, that concatenates these threevalues and displays it in an applet field. ProcessProperty4 would be of type string and would geta value as an Output Argument on a step. The Output Argument would be of type Expression asshown below:

Figure 10. Process Property Used as an Output Argument

Developing Workflows in Siebel ToolsThe following section brings out some points with Siebel 7.7 Workflow in Siebel Tools anddeveloping on a local database.

Workflow is a repository object. Workflow belongs to a project. In Siebel 7.7, workflow does notparticipate in the following behaviors that are standard for other repository objects

• SRF – workflow has its own deployment mechanism, the details of which can befound in the Business Process Designer Administration Guide

• Merge – workflow does not participate in the 3-way merge. When workflow definitionsare imported into the repository, they maintain versioning provided by workflow

•

Object Comparison – disabled for Siebel 7.7• Archive – workflows do not participate in .sif archive. Instead, workflows can be

archived as XML files using workflow export utility.

Typically, developers use local database to develop workflows. When using local database,workflow definitions need to be checked-out from the master repository.

When developing workflows in local database, it would require the local database to have all thereferenced data objects. For those data object that are not docked and hence not packaged aspart of the database extract, they would need to be imported into the local database. Thefollowing objects are not docked and are referenced by workflow

• Data Maps

• Message tables

To import data maps to the local database, you would use the dedicated client connected to thelocal database and use the client-side import utility. Message tables can be copied over to thelocal database. Alternatively, developers can define messages using the unbounded picklist.This allows the creation of the messages but does not check the validity of the message atdefinition-time.

Developers can also develop or modify workflows using Siebel Tools connected to thedevelopment database by locking the project in the master repository. This way, they do notneed to make sure that all the list-of-values are made available to the local database

of 56

8/6/2019 Tech Note 581


Step 3: Identify and Build Exception Handling An exception represents a deviation from the normal processing flow. An exception can be asystem error or a user-defined error. The Stop step can be used in combination with theexception branch to notify the user of an error and terminate the workflow process instance. Here

are three different types of exception handlers:

1) Use a Stop step which can show a particular error message while processing. This could beused for real-time processing for credit card authorization or order validation, etc. This providescustomizable error messages including expressions.

2) You can programmatically handle exceptions and change the flow depending on whenexceptions are encountered. This is done by using exception branches. This provides a granularapproach to handling exceptions at each step. In the example below, when the Get OrganizationID step is unable to get data, the workflow is programmed to continue and hand over to LookupSender by Org step and if it fails send an email (Send Lookup Error eMail).

3) You can define a universal exception handler at the workflow level by setting Error Process

Name on the workflow. This will be invoked for any exception that happens on the workflow.This is used when you need a uniform exception handler across multiple steps in a workflow oracross multiple workflows. This helps also to reduce clutter on the workflow diagram itself.

Step 4: Test and Simulate Workflow Processes There is a two step approach to testing and troubleshooting a workflow: using the workflowsimulator, and event logs.

of 56

8/6/2019 Tech Note 581


SimulatorMost workflows can be tested using the simulator. Developers can use the workflow simulatorhosted in Siebel Tools to debug workflows. To use the simulator, you need to have mobile clientinstalled. The mobile client can connect to any database (i.e. development or test) that has thetest data needed to debug a workflow. In Siebel 7.7, developers can test interactive workflow andruntime-event-based workflows using the simulator. Long running workflows and those workflows

that invoke server components cannot be debugged using the Simulator. During debug, theprocess variables are displayed using the dynamic watch window.

Using Business Service SimulatorWorkflow can be run as a business service from the Business Service Simulator in Siebel Client.The workflows would need to be deployed before testing them from the business servicesimulator.

This approach is useful when script needs to be debugged in conjunction with workflow. Onewould set breakpoints in the script and execute the workflow in the mobile client. When theworkflow executes a service for which breakpoint is set, control will be returned to the ScriptDebugger in Siebel Tools.

Event LogsMore detailed information on the execution can be viewed in log files by setting event logs.Events used for logging are as follows:

• Event: Workflow Engine Invoked (EngInv)Description: Trace methods invoked and arguments passed

• Event: Workflow Definition Loading (DfnLoad)Description: Trace process and step definitions loaded into memory

• Event: Workflow Process Execution (PrcExec)Description: Trace process instance creation/completion. Trace process propertyget/set.

• Event: Workflow Step Execution (StpExec)Description: Trace step creation/completion, branch condtion evaluation, business

service invocation, business component insert/update.Refer to Siebel Bookshelf 7.7 > Siebel Business Process Designer Administration Guide > ForAdministrators: Administering Workflow Processes > Troubleshooting Workflow Processes >About Tracing and Event Log Levels > for an explanation on how to set these.

Step 5: Migrate to Production Once the workflows are tested, they are marked for deployment by clicking the Deploy button andthen checked into the master repository. Deployment of workflow is a two-step process:1. Using Siebel Tools, workflow definitions are marked for deployment. This is done by clicking

the Deploy button in Siebel Tools.2. Using the Siebel Client, workflows are activated from the Business Process Administration

view. The process of activation, writes the definitions from the repository tables to theruntime tables for the workflow engine to execute.

Workflow definitions can be migrated across environments, from Development to Production forexample, using one of the following migration utilities:1. Repository Migration Utility – this utility allows export/import of all repository objects. This

utility is best used to migrate workflow definitions when the business is ready to rollout therelease (for example, migrate all repository objects)

2. Workflow export-import utility – this utility allows incremental migration of workflow definitions.Using Siebel Tools, one would export the workflow from one environment and import the

of 56

8/6/2019 Tech Note 581


workflow to another environment. Import of workflows can be done in one of the followingways:

a. Using Siebel Tools, you would import the definition into the repository of the targetenvironment. Then the definitions are ready to be activated. This approach ensuresthat the version of the workflow definition that exists in the repository tables and theruntime tables are the same.

Figure 11. Incremental Deployment Using Import/Export

b. Using Siebel Client, you could import the definitions directly into the runtime tables.This approach bypasses the step of writing the definition into the repository tables ofthe target environment and activation from Siebel Client. This would cause the latest

version of the workflow definition in the runtime tables, used by the workflow engine,to be different from the version that resides in the repository tables. This approach isgood for testing a workflow in different environment but not a best-practicerecommendation for migrating workflows across environments. See Figure 12:

Test DB Production Test

Siebel ToolsWorkflowImport/exportutilit

Repositorytables

Runtime tables

Repositorytables

Runtime tables

Siebel Client3. Activate (writesdefinition toruntime tables)

XML

2. ToolsIm ort

1.ToolsExport

of 56

8/6/2019 Tech Note 581


Figure 12. Incremental Deployment Using Siebel Tools and Client

Step 6: Monitor Processes

Externalize parametersAs best practice development guidelines, workflow definitions should have parameters that areexternalized and not hard-coded. Having parameters hard-coded in workflow, developers would

need to change the definition when the workflows are migrated between environments andexecuted. For example, if the workflow is sending emails to a list of customers and theparameter is hard-coded with the customer list, the workflow would not work correctly in theproduction environment. Developers need to make sure that such input arguments are read indynamically.

In the examples section, a best practice example is provided on how to externalize parametersthat are used by workflows.

Troubleshooting of workflows in production environmentWorkflows in production environment can be debugged in one of the following manners.

1. Turn on tracing on the corresponding component, Workflow Process Manager, WorkflowProcess Batch Manager, Application object Manager and view the event log files. Fordetails on how to turn on tracing please refer to Business Process DesignerAdministration Guide or look at FAQ 1482 on SupportWeb.

2. Turn on monitoring level to 3-Detail or 4-Debug. At this level, each execution of aprocess (whatever component it is run from) will record state and process properties’value for each step. The information is then available in the Site map > Administration -Business Process > Workflow Instance Monitor > Process Instances/ Step Instances.Such levels of monitoring affect performance of the workflow engine. Hence suchsettings should be used for troubleshooting purpose only.

Test DB Production Test

Siebel ToolsWorkflow exportutility

Repositorytables

Runtime tables

Repositorytables

Runtime tables- Workflow V2

Siebel Client- 2. Client-side

import

XML

2. Client-sideTools

1.Tools

Incremental deployment using Export utility from Siebel Tools and Import utility from Siebel Client

of 56

8/6/2019 Tech Note 581


8/6/2019 Tech Note 581


Solution: Since the DisplayApplet event is a UI event, and the default web UI frameworkdesign is to use cache, the event only got fired when the first time no-cached view isaccessed. The workflow got triggered whenever the event is fired and worked correctly. Tomake field still work in this scenario, you could explicitly set EnableViewCache to FALSE in.cfg file.

4. Problem: If a buscomp has code on WriteRecord and the runtime event fires onWriterecord, which occurs first? Solution: WriteRecord runtime event is in essence a Post-WriteRecord event and will be firedAFTER the buscomp code is executed.

5. Problem: After you triggered workflow from a runtime event, you do not get the row-idof the record on which the event occurred.Solution: Runtime event passes the row-id of the object BO (i.e. primary BC) and not therow-id of the BC. Retrieve the row-id of the active BC using searchspecs (e.g. Active_row-id(process property) = [Id] defined as Type = Expression and BC = BC name)

6. Problem: Encountered the error <Cannot resume Process <x-xxxxx> for Object-id <x-xxxxx>. Please verify that the process exists and has a waiting status.Solution: This error typically occurs in the following scenario:

(1) A workflow instance is started and paused, waiting for a runtime event(2) The runtime event fires. The workflow instance is resumed and run to completion.(3) The runtime event fires for a second time. Workflow engine tries to resume the workflowinstance and fails, since the workflow instance is no longer in a Waiting state.

Deleting existing instances will not help. You should ignore the error message and proceed.Steps (1)-(3) need to occur, in that order, in the same user session for the error message tobe reported. As a result, the error message would disappear when the application is re-started.

Also, Purge only works on stopped/completed instances. In order to deletepersisted/incomplete instances, you will need to manually stop the instances first.

7. Problem: How do you access a different business object (BO) from a workflowprocess?Solution: Workflow architecture restricts the use of 1 BO to a workflow. Use a sub-processstep to access a different BO.

8. Cannot initiate process definition <process name>Solution: Verify that the workflow process exists, process status is set to Active, and theprocess has not expired.

9. Problem: OMS-00107: (: 0) error code = 4300107, system error = 27869, msg1 = Couldnot find 'Class' named 'Test Order Part A'OMS-00107: (: 0) error code = 4300107, system error = 28078, msg1 = Unable to createthe Business Service 'Test Order Part A‘

Solution: Make sure at least one .srf file is copied to SIEBEL_INSTALL\objects\<lang>directory

of 56

8/6/2019 Tech Note 581


8/6/2019 Tech Note 581


• Start

• Siebel Operation

• User Interact

• End

Place a connector between the steps as shown:

Figure 2. Add Four Steps and Connectors

Now you will give each step a meaningful name. Select each step and change its name asfollows:

Step Name

Start: <Id> StartSiebel Operation: <Id> Add Activity Plan to Oppty

User Interact: <Id> Display Activity PlanEnd: <Id> End

of 56

8/6/2019 Tech Note 581


Figure 3. Give Each Step a Descriptive Name

The name ofStep may bechanged in thePropertiesWindow OR inthe WF Steps

Applet.

1.4 Select the Siebel Operation (Add Activity Plan to Oppty) step in the Designer. You need toinstruct the workflow about what operation you want to perform (for example, query, insert, orupdate) and which business component to use for the operation. Using the Properties Windowsor WF Steps applet, set the following attributes for the step:

Property ValueBusiness Component Activity Plan

Operation Insert

of 56

8/6/2019 Tech Note 581


Figure 4. Set the Business Component and Operation Type

Select the step and then use theProperties Window or WF StepsApplet to set the Business

Component and Operation Type.

When you perform an Insert operation on a business component, you must supply a value for anyrequired field in the business component. In particular, to insert a new Activity Plan, you mustprovide the name of the Activity Plan template.

Select the Siebel Operation Step (Add Activity Plan to Oppty) step and right-click to display themenu. Note there are three choices at the bottom of the menu for configuring a Siebel Operationstep. Choose the Show Fields option from the menu.

of 56

8/6/2019 Tech Note 581


Figure 5. Right-click a Step to Display Additional Properties for the Step.

Notice that the WF Steps applet was replaced by the Input Arguments applet. Add a newrecord to the Inputs Argument applet.

Field Name Type ValueTemplate Literal Any valid activity template

name. For HOR 7.7,Introductory Sales Call. ForSIA 7.7, Consumer AccountApproval.

of 56

8/6/2019 Tech Note 581


Figure 6. Supply Required Field Values for the Insert Operation.

After choosing ShowFields, Tools displaysthe Input Argumentsapplet.

1.5 Now you can configure the User Interact step to display a view. Select the User Interact(Display Activity Plan) step. Using the Properties Window or the WF Steps applet, set thefollowing:

Property ValueUser Interact View Opportunity Activity Plan

1.6 Now you must tell the workflow what event will denote the end of the User Interact step.For example, you might want to wait for the user to enter additional data before continuing in theworkflow. For this example, you want to wait for the user to make and save a change to theActivity Plan record.

Select the Connector between the User Interact and End steps. Use the WF Step Branch appletto set the following properties for the branch:

Property ValueType Condition

Event Object Type BusCompEvent Object Activity PlanEvent WriteRecordUpdated

of 56

8/6/2019 Tech Note 581


Figure 7. User Interact Step Requires a Conditional Branch.

Choose the branchand set the conditionproperties in the WF

Step Branch applet.

Now that you have finished configuring the workflow, you will validate it for correctness.Right-click inside Designer and choose “Validate…” from the menu. When the Validationdialog opens, press Start. If any error is reported, follow the instructions to fix it and repeatthe validation until no errors are reported.

Step 2: Test the Workflow Using the SimulatorIn this section you will test the new workflow process using the Simulator.

Step Summary

2.1 Verify Debug Options for launching the Simulation Client

2.2 Set a process property for the Opportunity Id

2.3 Launch the Simulator

2.4 Step through the workflow using the Watch Window to monitor status

2.1 The Workflow Designer launches an instance of the Mobile Client executable to performthe Simulation. From the View menu in Siebel Tools, choose Options… and the Debug tab.Review the settings and modify as needed for your environment. Click OK to close the dialogwindow.

of 56

8/6/2019 Tech Note 581


Confirm that the Debug Options are correct by launching a test client using the F5 key.

2.2 Navigate to the Opportunities List view in the session and get the row-id of one record.Return to Siebel Tools and right-click the Workflow Designer and choose Show ProcessProperties from the menu. Note that the bottom applet now displays the WF Process Props.

Because this workflow is based on the Opportunity Business Object and attempts to add anActivity Plan to an existing opportunity, you need to specify an opportunity row-id for the

simulation. Find the Object Id process property in the list applet and set its default value to theOpportunity row-id found in the prior step.

of 56

8/6/2019 Tech Note 581


Use the Object Id DefaultString to provide a row-id forSimulation.

2.3 Close any running Mobile Client sessions now. You will not be able to use the Simulator ifthere are running sessions. Confirm there are no Siebel Client icons in the Task Bar beforecontinuing.

Right-click the Workflow Designer and choose Simulate from the menu.

Click the Start button at the top of the Simulation applet. This will launch the Mobile Clientexecutable. Wait for the Simulation In Progress dialog box to appear.

of 56

8/6/2019 Tech Note 581


Figure 8. Wait for Simulation in Progress Dialog to Appear before Returning to SiebelTools.

2.4 Alt-tab to return to the Tools session. To make the session easier to use, you may wish to

hide the Object Explorer and Properties Window. You may also wish to resize the Tools windowso it not does cover the full display.

Figure 9. SimulationView

of 56

8/6/2019 Tech Note 581


If the Watch Window is blank, right-click the Simulation applet and choose Watch Window fromthe menu. This will refresh the display.

Click the Next Step button to move between the steps.

After the Opportunity Activity Plan View is displayed in the Mobile Client, note that you cannotreach the End step by pressing the Next button. Since you specified a condition on the branchyou must satisfy the condition before reaching the End step. Therefore, using the Mobile Clientsession make and save a change to the Activity Plan BusComp (for example, change thePlanned Start Date or Description).

Press Alt-Tab to return to Siebel Tools and click Next to complete the End step.

When the last step is reached, the mobile client will display a dialog box reporting ”Simulationterminated! Please check the watch window for details.” Acknowledge the message and Alt-tab toreturn to Siebel Tools.

Review the status field in the Watch Window.

Figure 10. Simulation is Completed

If Status is COMPLETE. The workflow

ran without error.

of 56

8/6/2019 Tech Note 581


Right-click the Simulation Applet and choose Stop from the menu. This will terminate the MobileSession.

Step 3: Call the Workflow from the UI using a Runtime Event

Now that you’ve built and simulated a workflow, you need to decide where and how it will beinvoked from the user interface. For the purposes of this example, you will add a button to theOpportunity list applet to invoke the workflow.

Step Summary3.1 Add a new pushbutton to the Opportunity List Applet

3.2 Configure the pushbutton to Invoke a new event

3.3 Configure the workflow process to run when the event is detected

3.1 Return to your Siebel Tools session. If you have hidden the Object Explorer, press Ctrl-E tore-expose it. You may also hide the Watch Window.

Locate the Opportunity list applet and edit its Web Layout for Edit List Mode.

Drag a button control to the layout and set its properties as follows:

Property ValueCaption - String Override Create PlanHTML Type MiniButtonMethodInvoked EventMethodCreateActivityPlan

Name Plan Button

NOTE: Methods that use the naming format EventMethodxxx do not require any applet orbusiness component script to enable the event. If you did not use this special naming convention(for example, we set MethodInvoked=CreateActivityPlan) you would need to write aWebApplet_PreCanInvokeMethod script to enable the event.

Preview the applet.

of 56

8/6/2019 Tech Note 581


Figure 11. Add a New Button to the UI to Invoke a Synthetic Event

Save the applet changes and compile a new SRF in your client directory.

3.3 Now you will modify the workflow so that it launches whenever the methodEventMethodCreateActivityPlan is invoked. Return to the workflow process objects and query forthe Create Plan process created earlier. Right-click to edit the process.

Select the Connector between the Start and “Add Activity Plan to Oppty” steps. Set the propertieson the branch using the WF Step Branch applet as follows:

Property ValueType Condition

Event Object Type AppletEvent Object Opportunity List Applet

Event PreInvokeMethodSubevent EventMethodCreateActivityPlanEventCancelFlag Y

of 56

8/6/2019 Tech Note 581


Figure 12. Supply a Start Condition for the Workflow.

Call this workflow wheneverthe method namedEventMethodCreateActivityPla

n occurs on the OpportunityList Applet.

Validate the process. If there are no errors, you are ready to deploy the workflow.

Step 4: Deploy and Activate the Workflow ProcessNow you are ready to deploy and activate the workflow. These steps are required before the newworkflow can be called in the Runtime client.

Step Summary

4.1 Deploy the workflow from Tools

4.2 Activate the Deployed Workflow in the Runtime Admin Client

4.3 Enable Monitoring in the Runtime Admin Client

4.4 Reload Runtime Events in the Runtime Admin Client

4.1 Return to your Siebel Tools session. Double-click the Workflow Process category in theObject Explorer so that the list of workflow processes is displayed. If Create Plan is the not theactive row, query for it and select it.

Click the Deploy button at the top of the screen. The status of the Create Plan workflow willautomatically change from In Progress to Completed.

of 56

8/6/2019 Tech Note 581


Figure 13. Workflow Deployment.

After theprocess isdeployed, theStatus fieldchan es to

4.2 Launch the Runtime Administration Client using a short-cut or the F5 key. Connect usingSADMIN or an equivalent admin account.

Using Site Map, navigate to Administration-Business Process > Workflow Deployment. This willdisplay the following view:

of 56

8/6/2019 Tech Note 581


Figure 14. Workflow Deployment View

Query for the Create Plan process in the top applet named Repository Workflow Process. Onerow should be returned. Click the Activate button in the top applet.

Now query for Create Plan in the lower applet. One row will be returned for every version thatwas activated for the process.

of 56

8/6/2019 Tech Note 581


Figure 15. You Must Activate a Workflow After Deploying from Siebel Tools.

4.3 In the lower applet named Active Workflow Process, set the Monitoring-Level to 4-Debug.

Now you can verify that a runtime event was created for this workflow. Using Site Map, navigateto Administration – Runtime Events > Events.

4.4 From the applet menu, choose Reload Runtime Events.

Query for the method you are using to invoke the workflow (Subevent =EventMethodCreateActivityPlan). It should return one row.

Figure 16. A Runtime Event will Invoke the New Workflow.

of 56

8/6/2019 Tech Note 581


Step 5: Test the Workflow using the Runtime ClientNow you are ready to call the workflow using the button on the Opportunity list applet.

Step Action

5.1 Open the Opportunity List View and press the Create Plan button

5.2 Make and save a change to the Activity Plan5.3 Review the workflow process log

5.1 Using the Runtime client, navigate to the Opportunity list view and press the Create Planbutton.

Figure 17. Test the workflow using the UI.

Invoke the workflow foran opportunity.

5.2 After the workflow navigates you to the Opportunity Activity Plan view, verify that a new planwas created. Edit the plan description and save the change.

of 56

8/6/2019 Tech Note 581


Figure 18. New Activity Plan was Added to the Opportunity.

5.3 Using Site Map, navigate to Administration – Business Process > Workflow Instance Monitor.

Query for the Create Plan process. The related instance data will be displayed in the bottomapplet. Select the Step Instances tab to review the detail.

If your workflow runs without error, you can turn off monitoring by using Administration – BusinessProcess > Workflow Deployment. Query for Create Plan in the lower applet. Set Monitoring Levelto 0-None

Example 2: Creating Workflow Process Triggered by Runtime Event

In this example, you will create a simple workflow process that is initiated by a runtime event.You will become familiar with elements involved with setting up this workflow and see that theworkflow process and runtime events work.

Business Scenario: A workflow detects a service request being taken ownership of, thenautomatically creates an activity of type, Research. It then provides the owner with initial itemsthat can be used to research.

Steps

1. Launch Siebel Tools connected to sample database.2. Create a Test project3. Create a new Workflow with the following properties:

Name: SR Assigned - Auto Create ActivitiesBusiness Object: Service Request (object we are monitoring)Group: <leave blank as it is not required and not used by workflow>Autopersist: No

of 56

8/6/2019 Tech Note 581


Workflow Mode: Service FlowProject: Your Test projectDescription: <Provide something>

4. Open the Workflow Process Designer by right-click on the new row and choose Edit WorkflowProcess.

5. Drag the following objects from the Palette to the Designer:

Start Siebel Operation End

6. Once the icons are on the palette, drag Connector icons () onto the palette and connectfrom one step to another.

NOTE: Ensure that when the connector is highlighted, the end points of the connectors are inred, which means the connector is fully connected to the steps.

7. Rename the steps as shown above.

of 56

8/6/2019 Tech Note 581


8. Create a condition on the branch coming from the Start step.

Branch Name: SR Owner field updatedType: ConditionEvent Object Name: BusCompEvent: SetFieldValue

Event Object: Service RequestSubevent: Owner

9. In the Conditions applet, create a condition to check that SR [Owner] field must be set to avalue (the SR has to be assigned and can not be left blank). Create a new record and specify thefollowing:

Compare to: Business ComponentOperation: Is Not NullBusiness Component: Service RequestBusiness Component Field: Owner

In the Values field, leave this blank because we are checking [Owner] field is not null, thus noneed to check against any particular value.

Return to the Designer.

10. In the Process Designer, select the Siebel Operation icon and double-click into it to view theOBLE

of 56

8/6/2019 Tech Note 581


In the Siebel Operation applet, specify the following:

Name: Create Research ActivityOperation: InsertBusiness Component: Action

Right-click to open the Fields applet. In the Fields applet, specify the fields to populate wheninserting a new record into the Action business component. Please note that when performinginserts into a business component, ensure that any required fields for the business componentsare specified in this step or have pre-default settings from the Business Component > Fieldconfiguration in Siebel Tools.

For our test case, we will populate the following fields:

Field Name Type Value------------- --------- -------------------

Type Literal ResearchDescription Literal Research the following: Siebel Bookshelf, SupportWeb

In the Process Designer view, do a quick check of all icons and connectors to ensure they areconnected.

11. Go back to the All Processes applet. Query for you process. Click the Deploy button.

of 56

8/6/2019 Tech Note 581


12. Activate the workflow. Launch the client. Navigate to Site Map > Administration-BusinessProcess > Workflow Deployment. Query for your flow. Then, click the Activate button.

Next, Query for your flow in the lower applet (Active Workflow Processes). One row should bereturned for every version that was activated.

In the lower applet set the Monitoring Level to 4-Debug.

13. Test the workflow process being invoked by the runtime event:

a. Navigate to Site Map > Service Requests screen > All Service Requests view, create a newservice request record and step off the record.

b. Re-select the service request record and click on the Activities tab, this will display an activitywith the following:

Type: ResearchDescription: Will research the following: Siebel Bookshelf, SupportWeb

c. Once this activity is created, this confirms that the workflow was triggered by the runtime eventand the workflow was invoked and executed accordingly.

of 56

8/6/2019 Tech Note 581


Example 3: Creating a Service Mode Workflow The goal of this example is to introduce you to the Workflow Mode [Processing Mode] field and itseffect on the workflow process execution.

Business Scenario: A new Service Request is created by a user, workflow detects this andperforms the following:

• Automatically assign the new service request to the creator

• Changes the SR Sub-status to Assigned to reflect the ownership

• Automatically set the Commit time on the SR depending on the priority

• Create an activity with a set of steps which the owner can follow towards researching forthe SR

Steps:

1. Launch Siebel Tools connected to the sample database.2. Create a Test project3. Create a new Workflow with the following properties:

Name: New SR CreatedBusiness Object: Service Request (object we are monitoring)Group: <leave blank as it is not required and not used by workflow>Autopersist: NoWorkflow Mode: Service FlowProject: Your Test projectDescription: provide some description

3. Open the Workflow Process Designer by right-clicking on the new row and choosing EditWorkflow Process.

4. Drag the following objects from the Palette to the Designer:

Start Decision Point Siebel Operation Siebel Operation Siebel Operation SiebelOperation Siebel Operation End

5. Once the icons are on the palette, arrange them as seen in the diagram below, then dragConnector icons () onto the palette and connect from one step to another.

NOTE: To make the connectors bended, highlight the connector > right-click > Add Point. Thenclick on the new point (small white square box) and drag it to the desired location in the ProcessDesigner.

Make sure that when the connector is highlighted, the end points of the connectors are in redcolor, which means the connector is fully connected to the steps.

Double-click on each step and branch to rename them as is shown in the diagram below:

of 56

8/6/2019 Tech Note 581


6. Click on the New SR Created by User step.

Right-click and select Show Branches. Specify the following information:

Branch Name: Check SR PriorityType: ConditionEvent Object Name: BusCompEvent: WriteRecordNewEvent Object: Service Request

This information is to have workflow run when a new Service Request is being created.

7. Select the Decision Point step. If not done yet, set the Name = “Check SR Priority”. This stepchecks the value of the Service Request [Priority] field.

Right click and pick Show Branches, create 5 new records if you have not done so. Set the Typefield to “Condition”. Select the Connector, right click, pick Edit Conditions and define the

Conditions:

• 4 corresponding to a Priority value. Depending on the priority value, the workflow sets adifferent value for the Commit Time.

• 1 is for default when there isn’t a match for the priority, i.e., Priority not set. In this case,don’t set Commit Time, just create the activity.

The 5 records would look like the following:

of 56

8/6/2019 Tech Note 581


Priority 1-ASAP

Priority 2-High

of 56

8/6/2019 Tech Note 581


Priority 3-Medium

Priority 4-Low

of 56

8/6/2019 Tech Note 581


If Priority not set

There are no conditions on this branch.

Once all conditions and values are set, return to the Designer canvas.

8. Select the Siebel Operation step named “Set Commit Time In 1 Hour” that comes from the Prio1 branch. In this step, we will update the Service Request by setting the Commit Time accordingto the priority level, set the owner to the Service Request creator and also set Sub-status =Assigned.

Set the following fields and values as follows. To set the fields, right-click on the Operation stepand choose the Show Fields option.

9. Select the Siebel Operation step named “Set Commit Time In 2 Hours” that comes from thePrio 2 branch. In this step, we will update the Service Request by setting the Commit Timeaccording to the priority level, set the owner to the Service Request creator and Sub-status =Assigned.

Set the following fields and values as follows. To set the Fields, right-click on the Operation stepand select the Show Fields option.

of 56

8/6/2019 Tech Note 581



Set the following fields and values as follows. To set the Fields, right-click on the Operation stepand select the Show Fields option.


Set the following fields and values as follows. To set the Fields, right click on the Operation stepand select the Show Fields.

12. Select the Siebel Operation step named “Create Plan of Action Activity”. This step will createan activity for the service request with a set of actions that owner can follow. Set the followingfields and values as follows:

of 56

8/6/2019 Tech Note 581


The Comments field value can contain any text of your preference, such as below:

Plan of Action:

1. Verify if any attachments have been provided for the issue logged.

2. Ensure understanding of behavior logged by customer. If anything is unclear, check withcustomer and get clarification.

3. Check if there is anything that can be tested for the behavior.

4. Request logs where appropriate and applicable.

5. If any references found in Bookshelf, provide them to customer for review.

13. Verify the workflow process works in real-time, invoked by runtime event.

Deploy the workflow from Tools

Activate the workflow process by clicking on the Activate button in the client.

14. Since the workflow process has a runtime event that initiates the workflow, thepersonalization data and cache needs to be updated via reloading runtime events. Do this bygoing to any of the views in the Runtime Event Administration screen, select the applet menubutton > Reload Runtime Events menu item.

15. Test the workflow process being invoked by the runtime event:

Navigate to Site Map > Service Requests > All Service Requests view, create a new servicerequest record, set a value for [Priority] field or leave it blank. Save the record.

When you step off the record, you will notice the client application freeze or delay slightly with anhourglass. Re-select the service request record and check the [Owner], [Substatus] and [Date

Committed] fields. Verify they have been populated correctly. Check the Service Request >Activities view for the new activity.

Click on the Activities tab, this will display the new activity record. View the Comments field.

of 56

8/6/2019 Tech Note 581


16. Test out a few scenarios by creating service request records with different [Priority] valuesand see how the workflow process decision step behaves.

Example 4: Runtime Event Workflow with User Interact Step to

Navigate User to a View The goal of this example is to create a simple workflow process that is initiated by runtime eventand takes you to a view. This is an Interactive Flow.

Business Scenario: A new Service Request is created by a user, workflow detects this andperforms the following:

a. Automatically assign it the new service request to the creatorb. Changes the SR Sub-Status to Assigned to reflect the ownershipc. Automatically set the Commit time on the SR depending on the priorityd. Create an activity with a set of steps which owner can follow towards researching for the SR.e. Navigates the user to the Service Request > Activities view to display the newly createdactivity.

Steps

1. Launch Siebel Tools connected to sample or server database.

2. Navigate to Workflow Process.

For this example, we will re-use the workflow process from the previous example and modify itslightly.

3. Select the workflow process “New SR Created”. Revise this workflow process for an InProgress version. For the In Progress version, rename it to “New SR Created - Take User to SRActivity view”

Change the Workflow Mode to “Interactive Flow”

4. Deactivate all previous workflow processes based on Business Object = ‘Service Request’, sothat they do not run or interfere with invocation of the workflow for this lab.

5. In the Process Designer, perform the following:

a. Highlight the User Interact icon, drag and drop it into the Process Designer in between thesteps “Create Plan of Action Activity” and “End Workflow”.

b. Then, add connectors from “Create Plan of Action Activity” to the User Interact step, and thenfrom the User Interact step to the “End Workflow” step, as follows:

of 56

8/6/2019 Tech Note 581


6. Select the User Interact step in the Process Designer. In the User Interact step details view,make the following modifications:

a. Change the Name of the step to “Display SR Activities View”b. For the View field, bring up the pick applet and select “Service Request Detail View”, click OKon the User Interact View pick applet.

If you are not sure which is the correct view corresponding to the UI, this can be checked bygoing to the Service Request screen > All Service Requests view > Activities view tab, thenperform Help > About View. This will show the view’s configuration and the repository viewname.

c. Create an event coming from the User Interact step.

7. Deploy the workflow. Go to the Process list applet and click the deploy button.

8. Open the client and navigate to Administration-Business Process > Workflow Deployment.Query for the “New SR – Take User to Activity”. Press the activate button. In the lower appletquery for the same process. One row will be returned for every version that was activated. Makesure only the latest version is active. Set the Monitoring Level to 4-Debug. In the upper appletmenu choose “Reload Runtime Events”.

9. Test the “New SR Created - Take User to Activity” workflow process as follows:

a. Navigate to the Service Request list view

b. Create a new service request and specify a Priority level and step off the record.

Note that the application freezes with an hourglass. Afterwards, the [Owner], [Sub-Status] and[Date Committed] fields are populated and a new activity is created.

of 56

8/6/2019 Tech Note 581


Additionally, the application automatically navigates the user to the Service Request > Activitiesview to display the new activity record.

Also verify that the Workflow Process Log view has a process instances for “New SR Created -Take User to Activity”.

Example 5: Externalize parameters to be used by workflow The purpose of this example is to provide a framework to externalize workflow parameters suchthat workflows using business services that interact with external systems do not requirerepository changes when migrating between development, test and production Siebel instances.

OverviewWorkflows using business services that require interaction with external systems, for example,EAI HTTP Transport, which requires the URL of the external system for the input argumentHTTPRequestURLTemplate, need to be changed when the repository is migrated betweendevelopment, test, and production. The URL for workflow using the EAI HTTP Transport businessservice would point to an integrated test system’s external URL in the testing instance and pointto a production external system URL in the production instance.

Basic idea for the design of the framework is to store all the Input Arguments of a businessservice that are in use in a given workflow into a file. In the Service_PreInvokeMethod Event ofBusiness Service, add the script to read values of these substitutable Input Arguments of abusiness service in use in a workflow from a file and set the Input Argument of the businessservice with values read from a file. This way, the file residing on production Siebel instanceserver(s) will contain values for production external systems, and the file residing on developmentor test Siebel instance server(s) will contain values for development test external systems. Inother words, Input Arguments values are not hard coded for such a service in the workflowdesign, but read at run time from a file in the Service_PreInvokeMethod Event Method script.

This framework relies on file, with a particular name, on each Siebel server being available for

reading. Otherwise, the business service will fail and the workflow will throw an error at thatbusiness service step, which is a desired behavior.

For any business service where the script is added to the Service_PreInvokeMethod event, it isexpected that an Input Argument called ExternalSystem is defined, and the argument’s valuematches that xml tag name of the child of the root element in the file.

This script code will set all the child elements of the second level parent (child of the rootelement) of the file as Input Arguments

Following are key requirements of framework for externalizing workflow parameters for certainbusiness services:

• Framework should make migration of repository workflows between development, test,

and production Siebel instances transparent. for example, workflows should no longerrequire any changes during migration between various Siebel instances.

• Framework should support current business services as well as future requirements.

• Framework should support all usage scenarios of a given business service used invarious workflows.

• Framework should be easy to manage and have a net effect of reducing the total cost ofownership of operational aspects of running the Siebel instance.

of 56

8/6/2019 Tech Note 581


DesignThe following two services, when used in the Workflow as a step, have Input Arguments that mayrequire changes when migrating repository between development, test, and production Siebelinstances.

• EAI HTTP Transporto SendandReceive Method Input Argument(s)

HTTPRequestURLTemplate• EAI SQL Adapter

o Query Method Input Argument ExtDBODBCDataSource ExtDBPassword ExtDBTableOwner ExtDBUserName

Assume that a given Siebel instance has integration points with third party HR, Finance, and UANsystems. In order to use above two services, the Input Arguments mentioned above forrespective business services need to be supplied in the Workflow step definition where theseservices are used. The following is an arbitrary XML Hierarchy file named ebizint.xml containingInput Arguments for above two services and their values. The parameters under Finance, HR,

and UAN are for illustration purpose only.

You can have any number of needed parameters with appropriate values. For a given usagescenario of a business service, any parameters that are not needed will do no harm. Also XMLHierarchy is completely arbitrary, one shown here is for illustration purpose only.

Given the above structure of the file, the following eScript code can be added to theService_PreInvokeMethod event of the two services mentioned.

of 56

8/6/2019 Tech Note 581


of 56

8/6/2019 Tech Note 581


Note the location of the ebizint.xml file. In a Windows environment, this file should be present onC:\ on all Siebel server(s) where above services could be invoked. The file needs to be maderead-only for the user id under which the Siebel service runs and write access should be deniedto all users.

There is no other ongoing maintenance required for this file. Whenever the values in the filechanges, for example, external system URL, this file needs to be updated with the correct valueson all Siebel Servers.

The following is an example usage of the EAI HTTP Transport business service, which has the

above eScript code in the Service_PreInvokeMethod event.

Concepts shown in this example could be easily extended for other business services providedby Siebel and can help avoid changes to Workflows when migrating the repository betweendevelopment, test, and production Siebel instances.

tech note 581

Documents