Co-existence of Siebel versions 6 and 7

Workflow monitoring approach

Author: Roman AgaevDate: Tuesday, May 22, 2007Contents1 Abstract42 Potential solutions52.1 Workflow Persistence (except service workflows: WF_PROC_VAL_CD)52.2 SARM (Siebel Application Response Management)62.3 Siebel Environment/Component Logging82.4 Workflow Instance Monitor82.5 Custom Workflow/Process Monitoring93 Criterions113.1 Solution complexity113.1.1 Computation complexity113.1.2 Time complexity113.2 Closely coupling113.3 Reliability123.4 Scalability123.5 Time to market123.6 Simplicity123.7 Contiguity to OOB124 Solution Matrix125 Conclusion135.1 Discussion136 Appendixes13

FiguresFigure 11: The workflow diagram example4Figure 12: Monitoring workflow overhead for workflow processes5Figure 23: ARM data structure7Figure 24: Workflow instance monitor view9Figure 25: Workflow example with error branch10

AbstractThe workflow in Siebel is a high level declarative programming language. The programs of that language look like diagrams when every step that the diagram has inside, in fact represents a method/function/internal function/sub process which is unrelated to other functional points that underlie other steps. In fact the workflow supports SOA1 Service oriented approach

concept and consists of unrelated functional points which are connected by the main invocation field2 The field consists of common memory and api

that the workflow infrastructure provides.Figure 11: The workflow diagram example

Generally the workflow may be of four different modes:Interactive

Service

Long running

7.0 Compatible

Every of those workflow modes assume different circumstances to be invoked in.Several considerations must be taken in attention before actual start of workflow massive usage, part of those considerations provided by the following figure:Figure 12: Monitoring workflow overhead for workflow processes

Potential solutionsThe following document section consists of several different approaches which allow monitoring over the workflow execution. It must be considered, that every of those solutions affects in some way original performance.Workflow Persistence (except service workflows: WF_PROC_VAL_CD)By using workflow persistence to store the state of a workflow process, you can build end-to-end workflows which include wait steps, sub processes, and other interruptions, and which maintain the active state of a process over short or long periods of time, with activity occurring in various parts of your enterprise. When persistence is set to TRUE, a user can continue with a workflow process that has been suspended. The suspended workflow appears in the users Inbox.Generally the option is used during the development process or within long-running workflows in order to allow waiting mechanism.Workflow persistence is an attribute of a workflow process that supports long-lived transactions within a single workflow process. Workflow persistence allows process resumption after a pause or a server crash. Workflow persistence saves and restores data when the process is resumed.The option of workflow persistence can be applied just on the following types of workflow:Interactive

Long running

7.0 Compatible

To set workflow persistence for workflow processes3 Persisted workflow processes are automatically purged once they complete running.

In Siebel Tools, from the Object Explorer applet, select the Workflow Process object.

In the Workflow Process list editor, select the process you want to work with.

In the Auto Persist field, choose YES using the drop-down picklist.

SARM (Siebel Application Response Management)The Siebel Application Response Measurement (Siebel ARM) feature captures timing data useful for monitoring the performance of the Siebel application. When enabled, Siebel ARM records and saves data in binary file format. The Siebel ARM post processing tool, accessed from the command line, converts binary files to a readable format and includes different types of analysis options. Review the Siebel ARM post-processing tool output to monitor the performance of the Siebel application.The ARM works on and handles the following topics:Figure 23: ARM data structure

Enabling and configuring Siebel Application Response Measurement (Siebel ARM) involves two tasks4 By default, Siebel ARM is disabled

Setting Siebel ARM parameters on the Siebel Server.

Setting Siebel ARM environment variables on the Web server.

The Workflow Process Manager Server component (or every other application object manger) is enabled for Siebel Application Response Measurement (Siebel ARM). Siebel ARM captures timing data useful for monitoring the performance of the Siebel application, and records this information to binary files. Siebel ARM settings affect the Workflow Process Manager as follows: When the Siebel ARM level is set to 1, the Workflow Process Manager business service records: The time it takes to execute a service method Examples of service methods in Workflow Process Manager are RunProcess and ResumeInstance. When the Siebel ARM level is set to 2, the Workflow Process Manager business service records:

The time it takes to execute a service method

The time it takes to execute a workflow step

The time it takes to write monitoring data to the disk Siebel ARM level 2 can help you determine the logging overhead when you increase the monitoring level of your workflow process.

Siebel Environment/Component LoggingFor detecting errors that are logged to server log files, the following settings should be noted. The default setting is to generate error logs. For workflow, the errors are logged in the WFProcMgr (or every other Application Object Manager if the workflow's been ran within the object manager main thread) log files. These log files contain the name of the process and the parameters specified for the execution of the process. For information only, this is the default setting, GenericLog (and other related parameters) parameter for appropriate component must be set to 1Workflow Instance MonitorUse this view to see the history of all workflow process instances in all states, as well as step instances and aggregate data. When the Monitoring flag is set for a deployed workflow process definition, the workflow process instance remains in the Workflow Instance Monitor view after it has completed and is no longer visible in the Workflow Instance Admin view. The Workflow Instance Monitor view provides a log of workflow instances. From the application-level menu, choose Navigate > Site Map > Administration - Business Process > Workflow Instance Monitor. The top applet in this view lists workflow definitions.The top applet shows the workflow definitions for all workflow processes that have monitoring turned on, that is, the Monitoring Level is not NONE. The other applets in this view are the following: Process Instances. This applet shows the related log instances for the selected workflow process. Step Instances. This applet shows the steps and process properties for the selected process instance. Aggregate Data. This applet shows aggregate data as a chart view for the selected workflow process5 Depending on the monitoring level set for the selected workflow process, you may see no records in the Step Instances and Aggregate Data applets

.Figure 24: Workflow instance monitor view

Log-writing frequency determines the frequency at which monitoring data is written to the disk. The frequency is optimized internally by the Workflow run-time environment, based on the workflow type and the monitoring level you select. You can set the log-writing frequency parameters directly only by using the Debug monitoring level. At the Debug monitoring level, the log is written to the disk after every step6 Enabling monitoring at any level incurs performance overhead to your workflow processes. It is best to set the monitoring level to 0 (None) or 1 (Status) on workflow processes running in production. Monitoring levels of 2(Progress) and higher should only be used for the debugging of workflow processes

.Custom Workflow/Process MonitoringThis approach assumes that in any case the common logging concept must be applied across the application.The logs may be triggered by on-the-fly error from within a custom script (try, catch)

The logs may be thrown by the user (try, catch, throw)

The logs may be triggered by on-the-fly error from within a custom workflow (error branch)

The logs may be just added during the development at interesting points of application (scripts, workflows, run-time-events, communication module)

Siebel has several paradigms of catching different types of logs:The global application object has its own storage of errors that occurs during the session

GetLastErrCode()

GetLastErrMessage()

The business service object has its own storage of errors that occurs during its usageGetLastErrCode()

GetLastErrMessage()

The global application object has an ability of custom tracing (logging). The functionality may be managed by the following functions:TraceOn()

Trace()

TraceOf()

The communication module provides an ability of error catching by usage of Communication Client business service or by profile definition (ErrorLog, Log etc):ShellUIExit()

ShellUIInit ()

ShellUIUpdate

The workflow mechanism provides an ability of its common tracing and catching an errors due to usage of errors branches within the workflow

Figure 25: Workflow example with error branch

All of those points that are described above lead to a conclusion that there is no single source of logging, that why there is place for considerations regarding the concept of common logging mechanism that as part of it may include workflow monitoring/tracing/loggingPossible solution is common cacheable business service that will be able to consolidate different approaches together and will provide an appropriate API for its utilization and GUI for results viewing.CriterionsThe following section of the document is coming to analyze described above solutions. The assumption is that the final solution need provide a real time monitoring with possible history visualization and without getting in unnecessary complexity to monitor a process context.Solution complexityComputation complexity7 As a branch of the theory of computation in computer science, computational complexity theory describes the scalability of algorithms, and the inherent difficulty in providing scalable algorithms for specific computational problems. That is, the theory answers the question, "As the size of the input to an algorithm increases, how do the running time and memory requirements of the algorithm change and what are the implications and ramifications of that change?" The theory places practical limits on what computers can accomplish.

Workflow persistence, Workflow process monitoring, Siebel Application Response Management, and simple object logging are provided oob and have no obligations and additional computational complexity except of standard usage complexity. In opposite the custom workflow/process monitoring has extended computational complexity.Time complexity8 The time complexity of a problem is the number of steps that it takes to solve an instance of the problem as a function of the size of the input (usually measured in bits), using the most efficient algorithm. To understand this intuitively, consider the example of an instance that is n bits long that can be solved in n steps. In this example we say the problem has a time complexity of n. Of course, the exact number of steps will depend on exactly what machine or language is being used. To avoid that problem, the Big O notation is generally used. If a problem has time complexity O(n) on one typical computer, then it will also have complexity O(n) on most other computers, so this notation allows us to generalize away from the details of a particular computer

Within the boundaries provided by current criterion all solution are very similar, because every one of them presents a result with complexity of O(a*n).Closely couplingNone of described concepts presents closely coupling problem.Reliability9 In general, reliability (systemic def.) is the ability of a system to perform and maintain its functions in routine circumstances, as well as hostile or unexpected circumstances.

Within the boundaries provided by current criterion all solution are very similar, but the custom workflow/process monitoring concept less reliable just because of its being custom one.Scalability10 Scalability, as a property of systems, is generally difficult to define [2] and in any particular case it is necessary to define the specific requirements for scalability on those dimensions which are deemed important. It is a highly significant issue in electronics systems, database, routers, and networking. A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system.

Within the boundaries provided by current criterion all solution are very similar, but the custom workflow/process monitoring concept presents additional scalability due to its ability to wrap any other logging solution and append additional functionality without going out of predefined boundaries of concept.Time to marketWithin the boundaries provided by current criterion all solution except custom workflow/process monitoring concept are very similar. The custom workflow/process monitoring concept presents extended time to market.Simplicity11 Simplicity is the property, condition, or quality of being simple or un-combined. It often denotes beauty, purity or clarity. Simple things are usually easier to explain and understand than complicated ones. Simplicity can mean freedom from hardship, effort or confusion. It may also refer to a simple living lifestyle.

Within the boundaries provided by current criterion all solution except custom workflow/process monitoring concept are very similar. The custom workflow/process monitoring concept presents combined solution.Contiguity to OOBWithin the boundaries provided by current criterion all solution except custom workflow/process monitoring concept are very similar. The custom workflow/process monitoring concept presents custom solution, but done by Siebel's internal tools.Solution Matrix

Table 41: Solution/Criterions matrixSolution\CriterionComputationalComplexityTimeComplexityCloselyCouplingReliabilityScalabilityTime to marketSimplicityContiguity to OOBTotal

Workflow Persistence9101010910101078

SARM99101091091076

Object Logging10101010910101079

Workflow Process Monitoring10101010910101079

Custom workflow /process monitoring891091098972

ConclusionAccording the analysis assembled by presented above table/matrix the preferred solution is Workflow Process Monitoring. Although Object Logging has got the same grade, due to its inability of real time monitoring & visualization the Workflow Process Monitoring feature is preferable.DiscussionAlthough the results of straight analysis of possible solutions for workflow mechanism monitoring, the common logging approach provided by custom workflow/process monitoring concept must be considered.Production environment characterized by its sensitivity to performance issues, therefore the main purpose is minimization of possible overheads due to multiplication of different logging mechanisms that possibly may work simultaneously within the application.AppendixesTechnical Note 449

Siebel Object Interface Manager

Siebel Developer's Reference

Siebel Communications Server Administration Guide

Siebel Object Interfaces Reference

Configuring Siebel eBusiness Applications

Roman Agaev, M.Sc, PMPOwner, Supra Information Technology ltd.

- -