Bookshelf Home | Contents | Index | PDF     

Siebel Database Upgrade Guide > Application Planning for a Siebel Upgrade >

Upgrade Planning for Siebel Workflow Designer

Platforms: Windows, UNIX, IBM z/OS.

Important changes were made for Siebel 7.7 and Siebel 8.0 to how workflows are upgraded. Use this topic to determine how these changes affect your upgrade.

Changes for Siebel 7.7

In Siebel 7.7, the Workflow Process Designer was moved to Siebel Tools. Workflow components and definitions are defined as Siebel Tools objects and are stored in the repository.

The upgrade script migrates workflows from the main Siebel Database to the repository. Before upgrading your development or test environments, make sure that they include all the workflows from your production environment.

The upgrade copies or moves all workflow definitions to the repository as follows:

  • Seed workflows. The old seed workflows are overwritten by new seed workflows. Their status is Inactive.
  • Customer workflows, status Inactive. These are converted to workflow definitions in the repository. They will not have a status.
  • Customer workflows, status In-Progress. These are converted to workflow definitions in the repository. Their status remains In-Progress.
  • Customer workflows, status Active. These are converted to workflow definitions in the repository. Their status is changed to Completed. These workflow definitions are not copied to the main Siebel Database. This means that after the upgrade, no workflows are deployed. You must manually deploy seed workflows and customer workflows after the upgrade.

The upgrade automatically migrates customized business service scripts that are called by workflow operations.

You must deploy and activate repository workflows in order to use them. Workflow policy object and policy program data is upgraded normally. No data is changed or lost. Database triggers are not upgraded. After the upgrade, you must regenerate database triggers.

For information on how to deploy workflows, see Siebel Business Process Framework: Workflow Guide.

Schema Changes

The main Siebel Database tables that contain workflow definitions have changed. The new tables contain the workflow definitions for deployed workflows. The definitions of workflows that are Inactive or In-Progress are located in the repository. The tables are named as follows:

  • Siebel Database tables containing workflow information begin with S_WFA.
  • Repository tables containing workflow information begin with S_WFR.
  • Siebel Database tables that contain workflow information for releases prior to Siebel 7.7 begin S_WF_ (note the underscore after WF). After the upgrade to Siebel 7.7, these tables are obsolete and are not referenced by applications.

Changes for Siebel CRM 8.x

As of Siebel CRM 8.x, the repository merge process preserves customizations you have made to seeded workflows. A seeded workflow is a Workflow Process object and all child objects shipped as part of a Siebel release.

Special pre-merge and postmerge steps have been added to the regular repository merge to allow merging customer-modified seeded workflows:

  1. Workflow pre-merge. When you start a repository merge, this step runs and prepares customer-modified seeded workflows in the Prior Customer Repository for the repository merge.
  2. Repository merge. After the workflow pre-merge completes, the main repository merge runs. The repository merge identifies modifications you have made to seeded workflows in the Prior Customer Repository. It then copies the modifications to the corresponding seeded workflows in the New Customer Repository.
  3. Workflow postmerge. After the main repository merge completes, the workflow postmerge runs and sets workflow versions in the New Customer Repository.

All three parts of the repository merge display in the status bar of the Merge Repositories dialog box when you perform a repository merge.

The workflow merge steps fit into the overall flow of a repository merge as follows:

  • Repository merge starts
  • Workflow pre-merge
  • Main repository merge
  • Workflow post-merge
  • ICL merge steps (If this is an ICL merge)
  • Merge ends
  • Run the postmerge utilities
Workflow Pre-Merge

When you start the repository merge, the workflow pre-merge step runs and prepares customer-modified seeded workflows for the repository merge.

If the workflow exists in both the Prior Customer Repository and New Siebel Repository, and the version number in the Prior Customer Repository is greater than 0, then the workflow is customer-modified.

For these workflows, the pre-merge process makes the following changes:

  • Deletes version 0 of the customer-modified seeded workflow in the Prior Customer Repository.
  • In the Prior Customer Repository, copies the most recent version of the customer-modified seeded workflow and sets the copy's version to 0.

    The most recent version of the workflow is the one with the highest version number and Status indicates Completed. This is called the version n workflow.

  • Sets the copy's status indicates Completed.

The workflow pre-merge creates a version 0 copy of version n in the Prior Customer Repository because the merge process requires that workflows it compares between repositories must have the same name, must be version 0, and must have Status indicates Completed.

Repository Merge

The main repository merge compares workflows in the Prior Customer Repository, Prior Siebel Repository, and the New Siebel Repository:

  • Customer-Modified seeded workflows. The repository merge copies the modifications to version 0 of the workflow to the Prior Customer Repository to the same workflow in the New Customer Repository. The merge also copies versions 1 through n of the workflow to the New Customer Repository.

    An exception is when a workflow's object attributes are different in all three compared repositories. This means the object is both customer-modified and has also changed in the new release. This causes a merge conflict.

    The repository merge handles workflow attribute conflicts in the same manner as other objects. The merge process typically resolves merge conflicts in favor of the New Siebel Repository. You can review workflow-related attribute conflicts in the Siebel Tools Application Upgrade attribute List screen.

    If you modify a seeded workflow by deleting any of its child objects, the merge process does not delete the child objects in the New Customer Repository. After the merge, you must review child objects and delete them as desired.

  • Unmodified seeded workflows. If the workflow exists in both the Prior Customer Repository and New Siebel Repository, and the highest version level is 0 in the Prior Customer Repository, then the workflow is unmodified.

    After the merge, the seeded workflow in the New Customer Repository will be the one that shipped with the new release.

  • Customer-Created workflows. If the workflow exists in the Prior Customer Repository but not the Prior Siebel Repository, the workflow is customer-created. The repository merge copies all versions of customer-created workflows to the New Customer Repository.
  • Customer-Deleted Workflows. If the workflow exists in the Prior Siebel Repository but not the Prior Customer Repository, the workflow is customer-deleted. The repository merge does not delete the workflow from the New Customer Repository. After the merge, you must review these workflows and delete them as desired.
  • Obsolete seeded workflows. If the workflow exists in the Prior Siebel Repository but not the New Siebel Repository, the workflow is obsolete. The repository merge does not copy obsolete seeded workflows from the Prior Customer Repository to the New Customer Repository unless they are customer-modified. After the merge, you must review customer-modified, obsolete workflows and delete them as desired.
Workflow Postmerge Step

The workflow postmerge step runs after the main repository merge completes and does the following for seeded workflows that are customer-modified:

  • Changes the version of the workflow from 0 to n + 1 and sets the n+1 version's workflow status to In Progress.

    For example, if the most recent version of customer-modified Workflow A in the Prior Customer Repository is version 3, then the merged version in the New Customer Repository will be version 4 and will have Status indicates In Progress.

  • Copies version 0 of the workflow from the New Siebel Repository to the New Customer repository. This reinstates the version 0 seeded workflow that shipped with the new release.
Status of Customer-Modified Workflows After the Merge

After the whole repository merge is complete, customer-modified seeded workflows appear as follows in the New Customer Repository:

  • Version 0. This is the seeded workflow that shipped with the new release.
  • Versions 1 through n. These versions are copied intact from the Prior Customer Repository.
  • Version n+1. This is the new merged workflow version. It is a combination of the seeded workflow that shipped with the new release and the modifications contained in version n in the Prior Customer Repository.
Logging

Workflow pre-merge and postmerge. The workflow pre-merge step and postmerge steps write to the same log file:

Tools_install_dir\bin\merge0_ver.txt

where:

Tools_install_dir is the directory in which Siebel Tools is installed.

Each time you run the merge process, the name of the merge0_ver.txt file is incremented, for example merge1_ver.txt.

If the log file contains the error IDS_ERR_DEV_MRG_PREMERGE_FAILED, this means that the pre-merge step could not delete one or more version 0 seeded workflows. This causes the main merge process to be unable to merge the customer-modified seeded workflow into the New Customer Repository. You must manually reimplement customizations to these workflows. You need not rerun the repository merge.

If the log file contains postmerge errors, create a service request (SR) on OracleMetalink 3, or contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services.

Main repository merge. The main repository merge logs workflow-related messages to the standard merge log file, merge0.txt. If you find workflow-related errors in this log file, create a service request (SR) on OracleMetalink 3, or contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services.

The main repository merge log file is located in the same directory as the workflow pre-merge/postmerge log file.

    
Siebel Database Upgrade Guide Copyright © 2008, Oracle. All rights reserved.