Siebel Workflow Process with Workspaces - Parallel Development & Deployment (20.7 and later)

Siebel 20.7 New Feature - Parallel Development/Deployment of Workflows

Continuing the monthly updates release model, Siebel CRM team released 20.7 earlier this week but is available as Controlled Availability (CA) release. CA release means customers would have to request access to download this release via support request. As part of this update, Siebel has moved Workflows to use workspaces completely, both for Design time as well as for Run time. This is a significant and much needed feature that helps make parallel development for Siebel much more seamless and agile. In summary, Workflow processes can be developed, tested, delivered and migrated to higher environments like any other repository objects e.g., Applets, Views, Business Components etc. This blog provides a detailed overview of the feature with its stated benefits.

Feature Details & Benefits

Parallel Development/Deployment of Workflows is part of a new framework for management of workflow processes. This applies to only Workflow process and doesn't apply to Workflow policy. So of the key aspects of the feature are:

Parallel deployment, execution, simulation and monitoring of workflows via Runtime Repository - Each workspace could have its own runtime workflow version very similar to other repository objects
Preview of Workspace to support parallel deployment of workflows
Migration of workflows from Design Repository (DR) environment to Runtime Repository (RR) via true runtime repository tables
Rollback support for workflows via Runtime Repository version rollback
No manual activation of workflows post full RR migration
Application Object Managers respect Workspace context

Workspaces

Each workspace and version can have different version thereby helping business to plan future changes without any impact to existing workflow process

Debug and inspect within workspace context before delivery Migration
Seamless migration support for both incremental and full RR migration plans - Helping with complete autonomous migration plan
Preservation of existing instances in the higher (RR) environments
Ensures consistency across all repository artifacts within the construct of a workspace

S_RR_WORKFLOW which has been there since 17.0 release is now used and it stores the compiled definitions (Runtime Versions) of Siebel Workflow processes that are activated and used. The tables S_WFA_DPLOY_DEF and S_WFA_DATA are no longer used or relevant starting 20.7 S_WFR_PROC - Still stores the design time definition of the workflow process in the Repository along with several child tables S_WFA_INSTANCE - Contains the state information of the specific instance of a workflow S_WFA_DEF_LOG - Contains the information needed for workflow monitoring

Workflow Process Operations - Comparison

Here we are providing a comparison of workflow process pre 20.7 with post 20.7. Pre Siebel 20.7

Design time Repository

Workflows was defined in S_WFR_PROC and its child tables
Available to use if "Inactive" field is not set to TRUE (Meaning workflow process is "Active") Migration
All Design time workflows are migrated to target RR environment during full migration
Modified workflow process definitions are migrated to RR environment during incremental migration and previous versions are deleted
Runtime (Deployment)
Workflow processes are deployed to S_WFA_DPLOY_DEF and also creates any required runtime events. Only active workflow processes are deployed
For full migration, manual deployment of workflows processes post migration or activated via the use of business service
Only one version of workflow may be deployed and used by Application Object Managers at run time.

Siebel 20.7 or later

Design time Repository "Inactive" field in S_WFR_PROC still relevant to define if a workflow process is active or not Only Active workflow processes are deployed automatically upon delivery Runtime (Deployment).

Deployed workflows are stored in S_RR_WORKFLOW upon delivery - Provides separation across workspaces, thereby aiding parallel development - Many versions of workflow can be active in a given environment across workspaces - AOM selects the relevant version per the workspace assigned to it - Runtime workflows correspond to the number of active workflow versions in the design time repository

Migration

Deployed workflows are migrated along with other Runtime Repository objects during both full and incremental migration Takes care of migration of S_WFA_DEF_LOG as well along with S_RR_WORKFLOW records Workflow Monitoring Monitoring of workflows is also workspace enabled Each active workflow in S_RR_WORKFLOW has a version in the monitoring table i.e., S_WFA_DEF_LOG with the workspace context and version number within that workspace

Uptake of Siebel 20.7

Pre-Requisites If a customer is already on 17.0 or later, it is better to install patch released by Oracle before applying 20.7. The objective of the patch is it inactivates any unused workflows using a command line executable called "InactivateWF". The patch evaluates the records in the S_WFA_DPLOY_DEF table and any workflow that is not deployed is assumed to be not used by the customer and is made inactive in the DR. In addition to inactivating the workflow, it also deletes the records in the runtime event tables like S_CT_EVENT_DEF, S_CT_EVENT, etc

DR and RR environments. At the end of the successful execution, it also updates the systempreference to indicate a WFUpgrade completed successfully.At the end of it a HTML report is generated. A snapshot of the HTML report is as shown below:

As part of this update to 20.7, Siebel CRM also preserves any Long Running Workflow Process that are in progress during migration activities. Upgrade/IRM to 20.7 For customers upgrading to 20.7 from pre-17.0, the full publish process will ensure that S_RR_WORKFLOW is populated with compiled definition of all active workflow processes in the DR environment. For a higher environment which is a RR only, the first full migration from source (DR) will populate the S_RR_WORKFLOW table. Due to this, the old records in S_WFA_DPLOY_DEF table are ignored and new runtime events are generated to invoke workflows using S_RR_WORKFLOW records. One limitation with the upgrade/IRM is that the Long Running workflow processes are not preserved.

Dymensions Perspective

Based on our evaluation of the new workflow framework using workspaces, we believe the new features related to Workflows are significant and very important for customers in their journey towards agility and parallel development/deployment. This was one of the gaps in prior Siebel releases and is a welcome addition to Siebel updates. The key missing piece with all these changes is the ability to edit/modify workflows using Siebel Web Tools, which Siebel CRM says is working towards and plans to release with a subsequent Siebel update. We believe that Siebel CRM should make this feature available as GA soon so that customers can start using them immediately. These changes along with a future update supporting enhancements to Siebel Web Tools will go a long way in making Siebel development more agile.

At Dymensions, we believe that most of Siebel customers want to not only get more value out of their existing investment but also use Siebel as a key aspect of their CRM strategy and potentially use other cloud based software services. We also believe that automated DevOps will bring customers business agility and also bring modern developer experience to its developer community.

Dymensions has been innovating using the modern tools and technologies to build DevOps solutions that will greatly benefit CRM customers and help them get more value out of their existing investment. We are committed to providing these solutions that will maximize the investment Siebel customers have already made in the product. For a demo of our solutions and for additional details, contact us using the information below.