Workflow On The Fly Monitoring Solution
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Workflow On The Fly Monitoring Solution

on

  • 2,775 views

 

Statistics

Views

Total Views
2,775
Views on SlideShare
2,773
Embed Views
2

Actions

Likes
2
Downloads
226
Comments
0

2 Embeds 2

http://supratech.co.il 1
http://www.supratech.co.il 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Workflow On The Fly Monitoring Solution Document Transcript

  • 1. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Workflow monitoring approach Author: Roman Agaev Date: Tuesday, May 22, 2007 -1-
  • 2. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Contents 1 Abstract.......................................................................................................................4 2 Potential solutions.......................................................................................................5 2.1 Workflow Persistence (except service workflows: WF_PROC_VAL_CD)....5 2.2 SARM (Siebel Application Response Management).......................................6 2.3 Siebel Environment/Component Logging........................................................8 2.4 Workflow Instance Monitor.............................................................................8 2.5 Custom Workflow/Process Monitoring...........................................................9 3 Criterions...................................................................................................................11 3.1 Solution complexity.......................................................................................11 3.1.1 Computation complexity.....................................................................11 3.1.2 Time complexity.................................................................................11 3.2 Closely coupling.............................................................................................11 3.3 Reliability.......................................................................................................12 3.4 Scalability.......................................................................................................12 3.5 Time to market...............................................................................................12 3.6 Simplicity.......................................................................................................12 3.7 Contiguity to OOB.........................................................................................12 4 Solution Matrix.........................................................................................................12 5 Conclusion.................................................................................................................13 5.1 Discussion......................................................................................................13 6 Appendixes................................................................................................................13 -2-
  • 3. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figures Figure 1-1: The workflow diagram example.................................................................4 Figure 1-2: Monitoring workflow overhead for workflow processes............................5 Figure 2-3: ARM data structure.....................................................................................7 Figure 2-4: Workflow instance monitor view................................................................9 Figure 2-5: Workflow example with error branch......................................................10 -3-
  • 4. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. 1 Abstract The 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 concept and consists of unrelated functional points which are connected by the main invocation field2 that the workflow infrastructure provides. Figure 1-1: 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: 1 Service oriented approach 2 The field consists of common memory and api -4-
  • 5. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figure 1-2: Monitoring workflow overhead for workflow processes 2 Potential solutions The 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. 2.1 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. -5-
  • 6. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. 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  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. 2.2 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: 3 Persisted workflow processes are automatically purged once they complete running. -6-
  • 7. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figure 2-3: ARM data structure Enabling and configuring Siebel Application Response Measurement (Siebel ARM) involves two tasks4  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. 4 By default, Siebel ARM is disabled -7-
  • 8. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. 2.3 Siebel Environment/Component Logging For 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 1 2.4 Workflow Instance Monitor Use 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. 5 Depending on the monitoring level set for the selected workflow process, you may see no records in the Step Instances and Aggregate Data applets -8-
  • 9. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figure 2-4: 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. 2.5 Custom Workflow/Process Monitoring This 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: 6 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 -9-
  • 10. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd.  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 usage  GetLastErrCode()  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 2-5: 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/logging - - 10
  • 11. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Possible 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. 3 Criterions The 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. 3.1 Solution complexity 3.1.1 Computation complexity7 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. 3.1.2 Time complexity8 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). 3.2 Closely coupling None of described concepts presents closely coupling problem. 7 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. 8 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 - - 11
  • 12. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. 3.3 Reliability9 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. 3.4 Scalability10 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. 3.5 Time to market 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 extended time to market. 3.6 Simplicity11 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. 3.7 Contiguity to OOB 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 custom solution, but done by Siebel's internal tools. 4 Solution Matrix 9 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. 10 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. 11 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. - - 12
  • 13. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Table 4-1: Solution/Criterions matrix Solution Computa Time Closely Reliab Scalab Time to Simplicity Contiguity Total Criterion tional Complex Coupling ility ility market to OOB Complex ity ity Workflow 9 10 10 10 9 10 10 10 78 Persistence SARM 9 9 10 10 9 10 9 10 76 Object Logging 10 10 10 10 9 10 10 10 79 Workflow 10 10 10 10 9 10 10 10 79 Process Monitoring Custom 8 9 10 9 10 9 8 9 72 workflow /process monitoring 5 Conclusion According 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. 5.1 Discussion Although 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. 6 Appendixes  Technical Note 449  Siebel Object Interface Manager  Siebel Developer's Reference  Siebel Communications Server Administration Guide  Siebel Object Interfaces Reference - - 13
  • 14. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd.  Configuring Siebel eBusiness Applications - - 14