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

Upgrade Planning for Siebel Workflow Designer

Platforms: Windows, UNIX, IBM z/OS.

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 premerge and postmerge steps have been added to the regular repository merge to allow merging customer-modified seeded workflows:

1. Workflow premerge. 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 premerge 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 premerge
• Main repository merge
• Workflow post-merge
• ICL merge steps (If this is an ICL merge)
• Merge ends
• Run the postmerge utilities

Workflow Premerge

When you start the repository merge, the workflow premerge 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 premerge 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 premerge 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, then 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, then 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, then 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, then 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 premerge and postmerge. The workflow premerge 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, then this means that the premerge 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, then create a service request (SR) on My Oracle Support, 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, then create a service request (SR) on My Oracle Support, 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 premerge/postmerge log file.