E Workflow Services Changes Between 10.1.2 and 10.1.3.1

This appendix provides an overview of changes to workflow services between releases 10.1.2 and 10.1.3.1.

This appendix contains the following topics:

• Backwards Compatibility between 10.1.2 and 10.1.3.1

• Changes Between the Workflow Wizard and the Human Task Editor

• Changes to Configuration Files

• Changes to Worklist APIs

• Changes to Task Display Form Deployment

• Changes to the Oracle BPEL Worklist Application

• Changes to Oracle BPEL Control

• Migrating Workflow Definitions from 10.1.2 to 10.1.3.1

See Also:

• "Oracle BPEL Process Manager Workflow Services 10.1.2 and 10.1.3.1.0 Compatibility" for additional details

• "Deprecated Workflow Service and Identity Service Functions"

• Oracle BPEL Process Manager Installation Guide for additional details about migrating projects that use the workflow service

E.1 Backwards Compatibility between 10.1.2 and 10.1.3.1

Workflows designed with the workflow wizard in 10.1.2 can be deployed and run in 10.1.3.1. You just have to redeploy the process. However, the instance tables for 10.1.2 and 10.1.3.1 are different. Therefore, 10.1.2 items do not show up in the 10.1.3.1 Oracle BPEL Worklist Application. To access tasks created from 10.1.2 processes, visit the old Oracle BPEL Worklist Application at

http://localhost:9700/integration/oldworklistapp/Login

The identity service configuration file must be modified as described "Migrating Workflow Definitions from 10.1.2 to 10.1.3.1". This modification is required even if you do not make any changes to your 10.1.2 processes. If you want to use any new 10.1.3.1 workflow features, you must manually migrate the process to use the 10.1.3 task definition. The changes to the task editor, form deployment, worklist, and configuration files are documented in later sections of this appendix.

E.2 Changes Between the Workflow Wizard and the Human Task Editor

For release 10.1.3.1, the Workflow Wizard that you used to design workflows in previous releases has been replaced with the Human Task Editor. You can still deploy 10.1.2 processes that include workflow functionality from Oracle JDeveloper. However, you cannot edit these workflows with the Human Task Editor. To use the 10.1.3.1 functionality, you must manually migrate the workflow task scope and recreate the human task.

Table E-1 describes the functionality of the 10.1.2 Workflow Wizard pages and the location of this functionality in the Human Task Editor.

Table E-1 Location of Workflow Wizard Functionality in 10.1.3.1

10.1.2 Workflow Wizard Page	Location in 10.1.3.1 Human Task Editor	See Section
Welcome — For creating a workflow model, performing advanced task configuration, and extending the functionality of an existing workflow Note: The pages that display if you select advanced task configuration are described later in this table.	To create a human task: Access the Human Task Editor. To extend an existing workflow: Go to the Advanced tab of the human task activity. Click the Include task history from check box.	"Accessing the Human Task Editor" to create a human task "Including the Task History of Other Human Tasks" to extend an existing workflow
Workflow Pattern — For selecting a workflow pattern to design, specifying a workflow name, and specifying a variable name Note: Workflow patterns are known as participant types in 10.1.3.1.	To select a workflow pattern to design. Go to the Assignment and Routing Policy section. Click the + sign to display the Add Participant Type window. Select a participant type from the Type list. To specify a workflow name: Right-click the BPEL process and select Create Human Task Definition. Specify a name in the Human Task Name field of the Add a Human Task window. or Go to the General tab of the human task activity. Specify a name in the Task Definition field. To specify a variable name: Go to the General tab of the human task activity. Click the flashlight in the BPEL Variable column to map the task parameter to the BPEL variable.	"Assigning Task Participants" to select a workflow pattern to design "Accessing the Human Task Editor" or "Associating a Human Worklist Task with a BPEL Process" to specify a workflow name "Specifying Task Parameters" to specify a variable name
Task Notifications — For selecting the status for sending a notification message to a recipient	Go to the Notification Settings section. Click the + sign to expand the section. Specify the task notification status.	"Specifying Participant Notification Preferences"
Task Details — For selecting task details such as task title, payload, payload display format, task creator, and expiration duration	To specify a task title: Go to the top of the Human Task Editor. Specify a name in the Title field. or Go to the General tab of the human task activity. Specify a name in the Task Title field. To specify a payload: Go to the Parameters section. Click the + sign to display the Add Task Parameter window. To specify a payload display format: Complete BPEL process design. Right-click the human task folder. Select a payload display format option. To specify a task creator: Go to the General tab of the human task activity. Specify a task creator in the Initiator field. To specify the expiration duration: Go to the Assignment and Routing Policy section. Click the + sign to display the Add Participant Type window. Select a participant type from the Type list. Click Advanced at the bottom for the selected participant type. Provide specific details.	"Specifying a Task Title and Priority" or "Specifying the Task Title" to specify a task title "Specifying the Task Payload Data Structure" to specify a payload "Selecting a Task Display Form" to specify a payload display format "Specifying the Task Initiator and Task Priority" to specify a task creator "Specifying a Time Limit for Acting on a Task" to specify the expiration duration for a single approver "Specifying a Time Limit for Acting on a Task" to specify the expiration duration for a group vote "Specifying a Time Limit for Acting on a Task" to specify the expiration duration for a management chain "Specifying a Time Limit for Acting on a Task" to specify the expiration duration for a sequential list of approvers
Task Outcomes — For selecting a possible outcome for the task	Click the icon to the right of the Outcomes field at the top of the Human Task Editor.	"Specifying a Task Outcome"
Assignees — For manually or dynamically selecting the user or group to whom to assign a task	Go to the Assignment and Routing Policy section. Click the + sign to display the Add Participant Type window. Select a participant type from the Type list. Select a method for manually or dynamically assigning the user or group to a task.	"Assigning Participants to the Single Approver Task" "Assigning Participants to the Group Vote Task" "Assigning Participants to the Management Chain Task" "Assigning Participants to the Sequential List of Approvers Task" "Configuring the FYI Assignee Participant Type" "Configuring the External Routing Service Participant Type"
Escalation policy — For selecting the method for escalating a task	Go to the Expiration and Escalation Policy section. Click the + sign to expand the section. Select Escalate after from the list. Provide specific details.	"Overview or Escalation and Expiration Policy" and "Escalate After Policy"
Renewal policy — For selecting a task renewal policy	Go to the Expiration and Escalation Policy section. Click the + sign to expand the section. Select Renew after from the list. Provide specific details.	"Renew After Policy"
Assignment policy — For selecting if a specific person or a specific number of people must act on the task. This lets you route tasks to multiple users in a sequence	Go to the Assignment and Routing Policy section. Click the + sign to display the Add Participant Type window. Select Sequential List of Approvers from the list. Specify the list of sequential approvers.	"Assigning Participants to the Sequential List of Approvers Task"
Routing policy — For selecting the method by which to route the task	Go to the Notifications section. Click the + sign to expand the section. Specify a routing method.	"Notifying Recipients of Changes to Task Status"
Outcome determination policy — For selecting a task outcome policy, such as the percentage for final outcome, default outcome, and early completion configuration	Go to the Assignment and Routing Policy section. Click the + sign to display the Add Participant Type window. Select the Group Vote participant type from the Type list. Go to the Majority Voted Outcome section. Provide specific details.	"Specifying Group Voting Details"
Management Chain Parameters — For selecting the management chain (initial assignee and other users such as a manager) to sequentially review this task	Go to the Assignment and Routing Policy section. Click the + sign to display the Add Participant Type window. Select Management Chain from the list. Specify the number of management chains in the Number of Approvers section.	"Specifying the Number of Approvers"
Reviewers — For manually or dynamically selecting the user or group to review this task (appeared only if the parallel workflow with final reviewer pattern was selected)	Model a parallel participant followed by a simple participant, which acts as the reviewer.
(Advanced Options) Optional Task Details — For selecting the task priority, task owner, and task identification key	To specify the task priority: Go to the top of the Human Task Editor. Select a priority from the Priority list. or, to override this setting: Go to the General tab of the human task activity. Select a priority from the Priority list. To specify the task owner: Go to the top of the Human Task Editor. Specify an owner in the Owner field. or, to override this setting: Go to the Advanced tab of the human task activity. Specify an owner in the Owner field. To specify the identification key: Go to the Advanced tab of the human task activity. Specify the identification key in the Identification Key field.	"Specifying the Task Title, Priority, Outcome, and Owner" or "Specifying the Task Initiator and Task Priority" to specify the task priority "Specifying a Task Owner" to specify the task owner "Specifying an Identification Key" to specify the identification key
(Advanced Options) Task Flex Fields — For extending the functionality of a task to capture data in addition to the payload	Flex fields are configured in the Oracle BPEL Worklist Application. You can promote any task parameter that uses simple types to flex fields. To use this functionality, log into the Oracle BPEL Worklist Application with administrator privileges. By default, the bpeladmin user has permissions to perform flex field mappings.	"Flex Field Mappings"
(Advanced Options) Restricted Task Actions — For restricting some common actions performed from Oracle BPEL Worklist Application during runtime	Click the + sign next to Advanced Settings. Click Configure Actions to display the System Action Details window. Select system actions to allow in the task.	"Overriding Default System Actions"
(Advanced Options) Version Tracking Attributes — For selecting the attributes to be version tracked	Version attribute configuration is not supported. The workflow service by default creates the task version when: Payload is changed Attachments are added, deleted, or updated When comments are added, the task is not versioned.

E.3 Changes to Configuration Files

Table E-2 describes the differences between configuration files. These files are located in the SOA_Oracle_Home\bpel\system\services\config directory.

Table E-2 Configuration File Changes

Configuration	File	Changes Between 10.1.2 and 10.1.3.1
E-mail server	ns_emails.xml	This file includes a new property called NotificationMode, which is used for both e-mail and wireless notifications: <EmailAccounts xmlns="http:// xmlns.oracle.com/ias/pcbpel/NotificationService" EmailMimeCharset="" NotificationMode="NONE"> Set this property as follows (NONE is the default): EMAIL — If you only want to set up e-mail, and not other channels such as voice, SMS, and so on ALL — If you want to set up e-mail and all other channels, such as voice, SMS, and so on The note in this file explains the settings in detail.
Wireless	ns_iaswconfig.xml	No changes.
Fax	ns_faxcoverpages.xml	No changes.
Workflow properties	wf_config.xml	This file now includes workflow property settings that previously appeared in pc.properties.
Global configuration properties	pc.properties	This file now defines only the global configuration properties. All workflow property settings are now defined in wf_config.xml.
Identity service	is_config.xml	The containment hierarchy has changed. This file now defines support for multiple realms and separate authentication and authorization providers. <?xml version = '1.0' encoding = 'UTF-8'?><ISConfiguration xmlns= "http:// www.oracle.com/pcbpel/identityservice/isconfig"> <configurations> <configuration realmName="jazn.com"> <provider providerType="JAZN" name="XML" service="Identity"> <property name="usersPropertiesFile" value="users-properties.xml"/> </provider> </configuration> </configurations> </ISConfiguration> The 10.1.2 format had only one realm: <BPMIdentityServiceConfig xmlns="http:// www.oracle.com/pcbpel/identityservice/isconfig"> <provider providerType="JAZN" name="xml"> <property name="userPropertiesFile" value="users-properties.xml"/> </provider> </BPMIdentityServiceConfig> The 10.1.2 is_config.xml file can be migrated to 10.1.3.1 format by copying the provider element from the old file to the provider element in the default configuration section of the new file.

See Also:

Oracle BPEL Process Manager Administrator's Guide for additional details about these configuration files

E.4 Changes to Worklist APIs

In 10.1.3.1, a new set of APIs is provided for interacting with workflow services. These APIs only support 10.1.3.1 workflow tasks, and cannot be used to query or update 10.1.2 tasks or task definitions.

For interaction with 10.1.2 tasks, the 10.1.2 APIs are still provided. These APIs can query and update 10.1.2 tasks and task definitions. However, they cannot be used for 10.1.3.1 tasks.

Table E-3 describes the worklist API changes between 10.1.2 and 10.1.3.1.

Table E-3 API Worklist Changes

Component	10.1.2	10.1.3.1
API Clients	Different APIs to support local Java client and remote EJB client are provided.	Several API clients (Java, local and remote EJB, and SOAP) are provided. Local and remote EJBs are now unified in a single API. To use the same API, modify the wf_client_config.xml file to use the appropriate communication protocol. The wf_client_config.xml file is populated by default at install time with the EJB and SOAP configurations necessary to switch between EJB and SOAP bindings. See Also: "Building Clients for Workflow Services"
Packages that contain the APIs:	oracle.tip.pc.api.worklist oracle.tip.pc.services.hw.worklist	oracle.bpel.services.workflow.client — The workflow client API oracle.bpel.services.workflow.metadata — Corresponds to the task metadata service, which exposes operations to retrieve metadata information related to a task oracle.bpel.services.workflow.query — Corresponds to the task query service, which queries tasks based on a variety of search criterion such as keyword, category, status, business process, attribute values, history information of a task, and so on oracle.bpel.services.workflow.report — Corresponds to the report query service, which creates reports such as unattended tasks, tasks priority, tasks cycle time, and tasks productivity oracle.bpel.services.workflow.runtimeconfig — Corresponds to the runtime config service, which manages metadata used in the task service run-time environment. It principally supports management of task payload flex field mappings. oracle.bpel.services.workflow.task — Corresponds to the task service, which exposes operations to act on tasks oracle.bpel.services.workflow.user — Corresponds to the user metadata service, which provides methods for managing metadata specific to individual users and groups

E.5 Changes to Task Display Form Deployment

Table E-4 describes the task display form deployment changes between 10.1.2 and 10.1.3.1.

Table E-4 Task Display Form Deployment

Issue	10.1.2	10.1.3.1.
Specifying the task display form	You specify the task display form to use during workflow design in the Worklow Wizard - Task Details window: Auto generate JSP Form XSL File JSP URL	You specify the task display form to use after completing human task design: Auto Generate Simple Task Form Custom Task Form See Also: "Task 3: Generating the Task Display Form"
Contents of the autogenerated JSP task form	Automatically creates two files to display the payload: task_name_WF_Form.jsp — a default JSP file task_name_WF_Fields.xml — a mapping file	The default layout is based on a three-region template: Header region — Displays task attributes such as title, priority, created date, assignee, and expiration date. This information is contained in the Header1.jsp file. Body region — Displays content based on task parameters. The information is contained in the payload-body.jsp file and payload-body.xml mapping file. Footer region — Displays comments, attachments, and a short history of the task routing. This information is contained in the Footer1.jsp file. A .tform file is also generated, which includes a template URI and region information. This file is part of the process deployment archive and is deployed during process deployment. See Also: "Automatically Generating a Simple Task Display Form"
Contents of the custom JSP task form	You write a JSP for payload presentation display in Oracle BPEL Worklist Application	Task display forms are generated using three templates and two default JSPs: Three Region JSP — Consists of header, body, and footer regions. These regions can be displayed using custom JSP, XSL, default JSP, or autogenerated JSP files. The automatically generated JSP displays the body region. Two Region JSP — Consists of the header and footer regions One Region JSP — Consists of the body region The two default JSPs are as follows: The header JSP displays task attributes such as task number, priority, title, and so on. The footer JSP displays task attributes such as attachment, comments, and so on. See Also: "Generating a Custom Task Display Form"
Directory structure of task form	JSP and mapping files appeared at the same level as the process.	Task display forms are packaged in an EAR file in the JDev_Oracle_Home\jdev\mywork\application_name\project_name\public_html\human_task_name\form directory.
Deployment target	Forms are deployed only if the process is deployed from Oracle JDeveloper. The autogenerated JSP is copied to the server during process deployment.	Forms are deployed with either Oracle JDeveloper or ant. A deployTaskForm target is automatically added to your build.xml to deploy task forms. The deployTaskForm target creates an EAR file and uses the OC4J deployment tool to deploy the form as a separate application. ant runs this target after running the deployProcess target, which deploys the BPEL process. During process deployment, the task display form is registered with the human workflow. See Also: "Deploying Task Display Forms"
Location of deployed task forms	All task display forms are deployed inside the sample worklist application under j2ee\home\applications\hw_services\worklistxpress\payload\bpel_WorkflowName_Version\.	Each task display form is a separate application and is deployed under j2ee\home\applications\default_Process_Name_Version_Workflow_Name\.This provides for better sharing of the task display application from multiple worklist applications.

E.6 Changes to the Oracle BPEL Worklist Application

Table E-5 lists the URLs for accessing the old and new Oracle BPEL Worklist Application. You access tasks created from 10.1.2 processes by visiting the old Oracle BPEL Worklist Application URL. You access designed in 10.1.3.1 with the Human Task editor by visiting the new URL.

Table E-5 Old and New Oracle BPEL Worklist Application URLs

Issue	10.1.2 Worklist Application URL	10.1.3.1 Worklist Application URL
Worklist URL	http://host:port/integration/oldworklistapp/Login	http://host:port/integration/worklistapp/Login
Worklist code location	Oracle_Home\integration\orabpel\samples\hw\worklistapp	SOA_Oracle_Home\bpel\samples\hw\worklistapp

See Also:

"Customizing the Worklist Application"

E.7 Changes to Oracle BPEL Control

In 10.1.2, the workflow definition was defined in the following locations:

• A configuration file

• As BPEL code inside the workflow scope

The generated BPEL code varied based on the workflow pattern you selected to design the process. The BPEL code in the process also used the task manager process for some of its functionality. Therefore, for every process that included human workflow, the audit trail showed the activities executed inside the scope. Also, every instance of the task included a corresponding instance of the TaskActionHandler BPEL process.In 10.1.3.1, workflows are completely metadata-driven. Therefore, the generated BPEL code is much simpler; it consists of several assigns followed by invoke and receive activities from the task manager service. The task manager is no longer implemented as a BPEL process. Therefore, the audit trail shows a simplified view of the task. Also, the audit trail has been enhanced to show the task history. Therefore, clicking the task activity queries the current state of the task and displays the status and assignees.

E.8 Migrating Workflow Definitions from 10.1.2 to 10.1.3.1

1. Identify the scope activities that include human workflows.

2. Create a new human task definition for each of the workflows identified in Step 1.

3. Give it the same name as the old scope.

4. Drag and drop a human task activity in your BPEL process.

   This creates a new 10.1.3.1 scope activity and switch activity.

5. Remove the 10.1.2 scope activity. However, do not remove the 10.1.2 switch statement.

6. Copy the case statements from the 10.1.3.1 switch to the 10.1.2 switch and retain any of the code that you have in the case blocks.

7. Remove the 10.1.3.1 switch activity.

8. Remove the 10.1.2 global task variable. When the human task is created in 10.1.3.1, a new variable is created.

9. Identify task forms used for the workflow by looking for the _form.xml and .jsp files.

   In 10.1.2, task forms are displayed by using the autogenerated JSP form, the XSLT template, and the user-defined JSP URL. For the autogenerated JSP form, you can use the 10.1.3.1 autogenerated simple task form. For the XSLT template and user-defined JSP, URL you can use the 10.1.3.1 custom task form.

   With the 10.1.3.1 custom task form, you must select the three region JSP template, which includes the header, payload, and footer regions. For the header and footer regions, you can use the default header and footer JSP, respectively. For the payload, you can use the XSLT or JSP type based on the 10.1.2 task form display.

10. Regenerate the task forms.

11. Redo any customizations that were performed on the old task forms.