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:
- 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
- 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")
- 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
- 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
- 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
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.7During 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.
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.