How To Create Workflow In Siebel

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

Some of the benefits of this feature include:

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

Some of the technical details related to this feature are:

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

Other Relevant Changes with Workflows

There are other changes that have been made with this architectural change. Those include:

Removal of the View "Repository Workflow Process" under Workflow Deployment - Since this is obsolete and no longer needed due to automatic deployment of workflows upon delivery of workflow changes to main/integration workspace
The child view of "Active Workflow Processes" under "Repository Workflow Processes" View has also been eliminated
In addition, several buttons and menu options like 'Activate', 'Deactivate', Import and Delete have been removed as they are obsolete
Debugging:

Enhancements made to debugging using Simulator and Developer Web Client. Need to use inspect feature to choose correct workspace at runtime and then invoke workflow to test before continuing with simulation

** Pending Features - Enhancement of Web Tools to include workflow editor including debugging workflows using Web Tools. Siebel team indicates that these features will come in a later Siebel update.

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

Update to Siebel 20.7

During the update of Siebel
20.7, SES update launches a Post DB Install Utility which executes a workflow upgrade step. This step ensures that the compiled definitions of workflow processes are generated in S_RR_WORKFLOW table for both DR and RR environments. At the end of the successful execution, it also updates the system preference 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. W e 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. W e 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.

Siebel 20.10 Update

Siebel 20.10 Update Continuing the monthly updates release model, Siebel CRM team released 20.10 last week. On first glance at the update notes from Oracle, the update didn't appear to have any new features except for certification of Linux version 8 and quite a few bug fixes. On closer look at the various documentation guides, it dawned on us that there were quite a few enhancements released by Siebel CRM team. These should have been called out in the update guide as these are some key enhancements that will help customers. So let's take a look at what these enhancements are: Siebel Migration Enhancements As of Siebel 20.10, Siebel has removed the requirement of direct database connectivity for migration application. That essentially means: Removal of dependency on JDBC Removal of network dependency - Thereby also eliminating any requirement that both migration app and Siebel database be in the same internet zone or require port to be open between two zones The removal of

Parallel Releases Development using Siebel Workspaces - Complete Solution

Parallel Development using Workspaces