Skip Headers
Oracle® Fusion Middleware Business Process Composer User's Guide for Oracle Business Process Management
11g Release 1 (11.1.1.7)

Part Number E15177-11
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A BPMN Flow Object Reference

This appendix provides a detailed description of each of the BPMN 2.0 flow objects that Oracle BPM supports.

This chapter provides specific information on about Oracle's implementation of BPMN 2.0. See Appendix F, "The Sales Quote Example Process" for a general introduction to BPMN using the Sales Quote example project. For general information about BPMN, including the formal specification, see http://www.bpmn.org.

This chapter is organized by the different types of tasks your business process must perform. It includes the following sections:

A.1 Using Swimlanes to Organize Your Process

This section shows you how to organize your process using swimlanes. It also describes how to use roles to determine which members of your business organization are responsible for performing the work of your process-based application.

A.1.1 Introduction to Roles

A key to designing a business process is determining the people and roles required to complete each of the tasks that require user interaction. Within your process, roles are used to model who is responsible for performing the work performed within your business processes. Roles enable you to define functional categories that represent job functions or responsibilities within your organization.

The roles defined in your process are also referred to as logical roles. When your Oracle BPM project is deployed to the runtime environment, these roles are mapped to LDAP roles that correspond to the users in your real-world organization.

Roles are assigned to the horizontal swimlanes that display the roles responsible for completing activities and tasks within your process. Business Process Composer enables you to create and edit the required roles within your process and assign them to swimlanes.

Using Oracle BPM Studio, you can also map roles to specific users using LDAP. Oracle BPM Studio also enables you to create more robust organizational models using organizational units, calendars, and holidays. See the Oracle BPM Modeling and Implementation Guide for more information.

A.1.1.1 Roles in Context

Process analysts are responsible for determining what roles are required when designing a business process.

The Sales Quote example defines the following roles:

  • Sales Rep: Sales representatives are responsible for creating and updating a sales quote until is approved by the other roles defined in the project.

  • Approvers: Approvers represent users who are responsible for approving the combination of products and pricing structure defined by the sales quote.

  • Business Practices: This role represents users who are responsible for viewing and approving the sales quote. Additionally, they have the authority to add additional approvers during the review of the sales quote.

  • Contracts: This role represent users who are responsible for approval of the terms specified in the sales quote and also for creating the formal legal documents that can be forwarded to the customer.

See Section F.2, "Introduction to the Sales Quote Example" for more information on the Sales Quote example project.

A.1.2 Introduction to Swimlanes

Swimlanes are the horizontal lines that run across the process editor. All flow objects must be placed within a swimlane.

Swimlanes can also be used to group flow objects based on the roles defined within your process. Swimlanes that contain user tasks must have roles assigned to them. Swimlanes visually display the role responsible for performing each flow object within your process. Additionally, you can have multiple swimlanes that are assigned to the same role.

Swimlanes can make your process more readable when you must use the same role in different parts of the same process.

When you create a new process, Oracle BPM Studio and Business Process Composer create a default swimlane. You can add additional swimlanes to your process as necessary. When adding interactive and manual activities to a process, you must assign a role to the swimlane.

Note:

You cannot delete a swimlane that contains the only start or end even of a process.

A.1.2.1 Swimlanes in Context

Figure A-1 shows a simple process split across multiple swimlanes. In this example, the SalesRep role is assigned to the first swimlane. Because the Enter Quote user task appears inside this swimlane, process participants assigned to the SalesRep role are responsible for performing this task.

Figure A-1 A Simple Business Process Split Across Two Swimlanes

Description of Figure A-1 follows
Description of "Figure A-1 A Simple Business Process Split Across Two Swimlanes"

In a real-world business process, the combination of swimlanes and flow objects within them can be complex. The Sales Quote example project, as described in Appendix F, "The Sales Quote Example Process", is an example of a more complex process using multiple swimlanes.

A.1.3 How to Add Roles and Swimlanes to Your Process

You can add roles and swimlanes to your BPMN process.

To add a new swimlane to your process:

  1. Right-click on a white area of the process editor canvas.

  2. Select Add Lane.

The new swimlane is created. By default, the swimlane is not assigned a role. You can add a role by editing the swimlane properties.

To add a new swimlane and role to your process by adding a new flow object:

  1. Open the process where you want to add a swimlane.

  2. From the component palette, select a flow object, then drag and drop it on the process canvas below an existing swimlane.

The new swimlane is created. By default, the swimlane is not assigned a role. You can add a role by editing the swimlane properties.

A.1.4 How to Edit Swimlane Properties

You can edit the properties of a swimlane in the process editor.

To edit swimlane properties:

  1. Move the cursor over the role name for the swimlane.

  2. Click the Edit icon.

  3. Determine if you want to use an existing role, or create a new one:

    To assign an existing role to a swimlane:

    1. Click the Use button.

    2. Select a role from the drop-down list.

    To assigning a new role to a swimlane:

    1. Click the Create button.

    2. .Enter the name of the new role in the text field.

  4. If you want to optionally add a custom icon to a swimlane, click Change, then select the icon you want to use.

  5. If you want to optionally change the background color of a swimlane:

    1. Click Implementation.

    2. In the implementation properties editor, enter the RGB value of the color or select a color from the color palette.

    3. Click Apply Changes.

A.1.5 Sharing Roles Between Business Process Composer and BPM Studio

Oracle BPM Studio enables you to integrate roles within complex organization models based on organizational units, calendars and holidays.

When editing a project or creating a project based on a project template in Business Process Composer, you can access the roles defined within the project. However, you cannot view or edit the organizational information defined within the project.

Additionally, you can create new roles using Business Process Composer. These roles are incorporated as part of the overall organization information of the project.

A.2 Defining the Start and End Point of a Process

This section describes the BPMN flow objects used to define the start and end of a process.

A.2.1 Introduction to Start and End Events

Start events are BPMN flow objects that define the starting point of a process. There are different types of start events that determine how process instances are created.

End events, in contrast, define the end point of a process. There are different types of end events that determine what happens when the process instance is completed.

Note:

In Oracle BPM, all BPMN processes must have at least one start and one end event.

Because start events define the beginning of a process, they do not have incoming sequence flows. Likewise, end events cannot have outgoing sequence flows.

However, except for the none end and start events, start and end events can have input and output to processes.

A.2.1.1 Specifying the Start Events for Different Types of Processes

When you create a new process Business Process Composer creates a message start and message end event.

You can change these defaults depending on the type of business process you need to create. Table A-1 shows the default start and end events for each type of process.

Table A-1 Start and End Events for Each Process Type

Process Type Default Start and End Event Types

Asynchronous service

Message start and end event

Synchronous service

Message start and end event

Manual process

None start and end event


See Section 5.1, "Introduction to Business Processes" for more information on the different types of processes supported by Oracle BPM.

Subprocesses contain none start and end events by default. These are the required start and end events and cannot be changed.

Event subprocesses contain a message start and none end event by default. However, you can change the start event to reflect the type of event you are handling.

A.2.1.2 Using Multiple Start Events in a Process

You can define multiple start points in a BPMN process. Multiple start points enable you to specify multiple ways of creating a process instance, depending on which start event is used.

Figure A-2 shows an example process that contains both a message start and timer start event.

Figure A-2 Using Multiple Start Events within a Process

Description of Figure A-2 follows
Description of "Figure A-2 Using Multiple Start Events within a Process"

This process can be started using a message event when called from another process or service. It can also be started based on a time interval if the process instance must be created automatically.

Using multiple start events enables you to have multiple ways of starting a process without having to create two separate processes.

A.2.1.3 Using Multiple End Events in a Process

End events mark the end of a process path. When you have only one end event in your process and the token reaches the end event, the process is stopped when the end event is reached.

Note:

Message end events can only be used to terminate processes initiated by a message start event. Additionally, if you have multiple message end events associated with a message start event, each of these message end events must have the same quantity and type of output arguments.

When you are using multiple end events, it is possible for different tokens to take different paths within a process. In typical cases, all parallel paths must reach an end event before the process is completed.

However, in the following special cases, a process instance can be stopped before all process paths have completed:

A.2.2 Defining How a Process Instance is Triggered

Oracle BPM supports the following ways of triggering a process instance:

A.2.3 Introduction to the None Start Event

The none start event is used when no instance trigger is specifically defined. Process analysts can use the none start event as a placeholder when the necessary start event of a process is unknown or is defined and implemented later by process developers.

Figure A-3 shows the default notation for the none start event

Figure A-3 The None Start Event

Description of Figure A-3 follows
Description of "Figure A-3 The None Start Event"

None start events are also used to specify the beginning of a process where the process instance is created by another flow object. In general, the none start event does not trigger a new process instance.

However, when used with the following, the none start even does trigger a new process instance:

  • Receive task: The receive task must have the Create Instance property set to true.

  • User task: The user task implemented with the initiator pattern

Similar to other start events, the none start event cannot have incoming sequence flows. It can only have default out-going sequence flows.

Note:

None events are always used to define the beginning of subprocesses.

A.2.3.1 The None Start Event in Context

Figure A-4 shows an example of the none start event within the Sales Quote example project. In this example, the none start event defines the start of the process. Additionally, since the process contains a user task implemented with the initiator pattern, the none start event triggers a process instance.

Figure A-4 The None Start Event within the Sales Quote Example Process

Description of Figure A-4 follows
Description of "Figure A-4 The None Start Event within the Sales Quote Example Process"

A.2.3.2 Data Associations

The none start event does not accept process input arguments.

A.2.4 Introduction to the Message Start Event

The message start event triggers a process instance when a message is received. This message can be sent from another BPMN or BPEL process or from a service.

Messages are types of data used to of exchange information between processes. Just as data objects are used to define the data used within a project, messages are used to define the data used between processes or between a process and a service.

Figure A-5 shows the default notation of the message start event.

Figure A-5 The Message Start Event

Description of Figure A-5 follows
Description of "Figure A-5 The Message Start Event"

Similar to other start events, the message start event cannot have incoming sequence flows. Message start events require a default outgoing sequence flow.

You can expose a BPMN process as a service that enables other processes and applications to invoke the process. To expose a process as a service, your process must begin with a message start event. Additionally, you must define the input arguments to the process which are the data objects passed to the message start event. See Section 14.1, "Defining Process Input and Output" for more information.

A.2.4.1 The Message Start Event in Context

Figure A-6 shows a modified version of the Sales Quote process. Here, the process begins with a message start event that initiates the process instance.

Figure A-6 The Message Start Event Within the Sales Quote Example Process

Description of Figure A-6 follows
Description of "Figure A-6 The Message Start Event Within the Sales Quote Example Process"

A.2.4.2 Using Process Input and Output Arguments

The message start event enables you to specify input and output arguments to a process. These arguments define the message that other processes or services must send to the process during invocation. See Section 14.1, "Defining Process Input and Output" for information on how to configure process input and output arguments.

A.2.5 Introduction to the Signal Start Event

The signal start event is similar to a message start event in that it is based on communication from another process or service. However, the message start event responds to a message sent to a specific process. In contrast, the signal start event is a response to a signal broadcast to multiple processes.

Signals can be broadcast from a BPMN process using the signal throw event. Using a combination of signal throw events and signal start events, you can invoke multiple processes simultaneously.

The signal start and throw events are added to a process by process developers. For information on implementing the signal throw event, see "Introduction to Communicating Between Processes Using Signal Events" in the Oracle BPM Modeling and Implementation Guide.

Figure A-7 shows the default notation for the signal start event.

Figure A-7 The Signal Start Event

Description of Figure A-7 follows
Description of "Figure A-7 The Signal Start Event"

A.2.5.1 The Signal Start Event in Context

The signal start and throw events are added to a process and implemented by process developers.

A.2.6 Introduction to the Timer Start Event

The timer start event triggers the creation of a process instance based on a specific time condition. You can configure the timer start event to trigger a process instance based on the following:

  • A specific date and time. For example, a process could be triggered on December 31, at 11:59 P.M.

  • A recurring interval. For example, a process could be triggered every 10 hours, 5 minutes, 32 seconds.

Figure A-8 shows the default notation for the timer start event.

Figure A-8 The Timer Start Event

Description of Figure A-8 follows
Description of "Figure A-8 The Timer Start Event"

A.2.7 Introduction to the Error Start Event

The error start event is used as the start event of an inline handler. Using inline handlers you can define a separate process flow to handle errors that occur within your process.

Figure A-9 shows the default notation for the none end event.

Figure A-9 The Error Start Event

Description of Figure A-9 follows
Description of "Figure A-9 The Error Start Event"

Note:

Note: Error start events can only be used within inline handlers. They cannot be used within normal process flows.

You can define multiple inline handlers to handle error conditions. However, you cannot define multiple inline handlers that use the same exception.

A.2.8 Introduction to the None End Event

The none end event is used to mark the end of a process path. When a token reaches a none end event, it is consumed. If there are no other tokens within the process instance, the instance is complete.

The none event is used when your process is not required to perform any action after it completes. It can also be used as a placeholder by process analysts, to be changed later during implementation by a process developer.

Figure A-10 shows the default notation for the none end event.

Figure A-10 The None End Event

Description of Figure A-10 follows
Description of "Figure A-10 The None End Event"

The none end event is always used to mark the end of a subprocess and event subprocess.

A.2.8.1 The None End Event in Context

Figure A-11 shows an example of the none end event within the Sales Quote example. In this example, the Sales Quote service task is used to save information about the sales quote to a database.

Figure A-11 The None End Event Within the Sales Quote Example

Description of Figure A-11 follows
Description of "Figure A-11 The None End Event Within the Sales Quote Example"

Because no other work can be performed when the token reaches the end of a process, a none end event is used. After all process tokens reach the none end event, the process instance completes.

A.2.9 Introduction to the Error End Event

The end error event is used when the end of a process is the result of an error condition.

Errors end events are typically used with the error boundary event. The error boundary event is used to change the process flow based on a specific error. This flow usually ends using an error end event. See Section A.8.3, "Introduction to the Error Catch Event" for more information on using the error intermediate event.

Figure A-12 shows the default notation for the error end event.

Figure A-12 The Error End Event

Description of Figure A-12 follows
Description of "Figure A-12 The Error End Event"

For information implementing the error end event, see the Oracle BPM Modeling and Implementation Guide.

A.2.10 Introduction to the Message End Event

The message end event is used to send a message to another process or service when the process is completed. The message end event is always used with either a message start event or message catch event.

Note:

When creating a process that has multiple end events, you must ensure that any tokens that reach a message end event were created by a message start event. For example, you cannot use a message end event to end a process instance initiated by a timer start.

Figure A-13 shows the default notation for the message end event.

Figure A-13 The Message End Event

Description of Figure A-13 follows
Description of "Figure A-13 The Message End Event"

For information on how to configure process output arguments using message end events, see Section 14.1, "Defining Process Input and Output".

A.2.11 Introduction to the Terminate End Event

The terminate end event is used to immediately stop a process. When a terminate end event is reached, the process stops immediately. There is no error handling or additional cleanup performed.

A.3 Adding User Interaction to Your Process

Many business applications require interaction from process participants within your organization. This interaction can be as simple as entering information into a form or can involve multiple work flows and multiple users.

This section describes the BPMN flow objects that are used to model how process participants interact with your business processes. It contains the following sections:

A.3.1 Introduction to Human Workflow

Many end-to-end business processes require manual interaction with the process. For example, users may be needed for approvals, exception management, or performing activities required to advance the business process.

Oracle Human Workflow provides comprehensive support for user participation by providing the following features:

  • Manual interactions with processes, including assignment and routing of tasks to the correct users or groups

  • Deadlines, escalations, notifications, and other features required for ensuring the timely performance of a task.

  • Organization, filtering, prioritization, and other features required for process participants to productively perform their tasks.

  • Reports, reassignments, load balancing, and other features required by supervisors and business owners to manage the performance of tasks.

For more information, see "Getting Started with Human Workflow" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

A.3.1.1 Introduction to Human Tasks

Human tasks are a component of Oracle Human Workflow. Human tasks enable you to interleave manual interactions with connectivity to systems and services within an end-to-end process flow. Human tasks are responsible for handling all interactions with users or groups participating in the business process. They do this by creating and tracking tasks for the appropriate users in the organization. Users typically access tasks through a variety of clients, including the worklist application, e-mail, portals, or custom applications.

Human tasks enable process developers to define how process participants interact with process-based applications created using Oracle BPM Suite and Oracle SOA Suite.

Using human tasks, process developers can define the interface and workflow for end user interaction by creating the following:

  • Roles and assignments

  • Deadlines and escalations

  • Presentations

Human tasks are reusable services that can be used within other processes that require the same UI. Human tasks are created using Oracle BPM Studio.

A.3.2 Introduction to the User Task

The user task represents a part of your process where a process participant is required to perform work. This can be a simple interaction, such as entering a form, or part of a more complicated workflow that requires input from multiple process participants.

Figure A-14 shows the default notation for the user task.

Figure A-14 The User Task

Description of Figure A-14 follows
Description of "Figure A-14 The User Task"

In the Oracle BPM Suite, process participants interact with your business application using the Process Workspace. The specific user interface elements, including the screens and panels that process participants see, are created using human tasks.

When designing a process, process analysts often add the user task to a process diagram. Process developers then create the necessary human tasks and implement them as part of creating the overall process-based business application.

When a token reaches a user task, the corresponding human task is performed. The token waits until the human task is completed before continuing to the next flow object.

See Section 5.5.1, "How to Assign a Business Catalog Component to a Flow Object" for procedures on how to assign elements from the business catalog to a user task.

For information on how implementing user tasks, see "Using Human Tasks" in the Oracle BPM Modeling and Implementation Guide.

Similar to other flow objects, the user task may contain incoming and outgoing data associations.

User tasks may also contain incoming and default outgoing sequence flows.

A.3.2.1 The User Task in Context

In the Sales Quote example, the Enter Quote task, shown in Figure A-15, represents entering information about the quote.

Figure A-15 The Enter Quote User Task

Description of Figure A-15 follows
Description of "Figure A-15 The Enter Quote User Task"

After the user enters information about the sales quote, the process flow passes through the outgoing sequence flow to the next flow object in the process.

A.3.2.2 Using Interactive Activities

Oracle BPM Studio enables you to add interactive activities to a process directly from the component palette. Interactive activities are short cuts based on the task routing and approval features of Oracle Human Workflow. See " Getting Started with Human Workflow" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for more information.

Table A-2 shows the interactive activities that are available in Business Process Composer component palette.

Table A-2 Interactive Activities

Pattern Description

Complex

Uses a complex routing flow that is defined within the human task.

Management

Uses the management chain pattern where the assignee is set to the management chain pattern for the process participant belonging to the group or role assigned to the swimlane.

FYI

Bases assignment on the participant, role, or group defined in the swimlane. Similar to the user interactive activity, but the FYI activity does not wait until completion before continuing.

Group

Uses the group vote pattern. The assignee for the task is automatically set to the role or group associated with the lane. This interactive activity can only be added to swimlanes that are assigned to roles or groups.

Initiator

The initiator pattern is used to create a process instance.


A.3.2.3 Using the User Task in Project Templates

Using Oracle BPM Studio, you can add human tasks to the business catalog. Process analysts can use these in Business Process Composer when working with projects created from project templates.

When adding the user task to a project template to be used within Business Process Composer, follow these guidelines:

  • Process developers must create any required human task services within Oracle BPM Studio before using the template in Business Process Composer. Human tasks can be implemented within a user task or this implementation can be performed when editing the project based on the project template.

  • However, if the human task service is being implemented for a user task that is sealed within a project template, you must also perform the implementation before using the project template in Business Process Composer.

A.3.3 Introduction to the Manual Task

The manual task represents a task performed by process participants that is outside the scope of Oracle BPM. Manual tasks are used as placeholders within your process to show work that is not managed by the BPMN service engine at runtime. Additionally, manual tasks do not appear in the Process Workspace application.

Note:

Manual tasks are not managed by Oracle BPM. The Oracle BPM runtime does not track the start and completion of the manual task.

Figure A-16 shows the default notation for the manual task.

Figure A-16 The Manual Task

Description of Figure A-16 follows
Description of "Figure A-16 The Manual Task"

Manual tasks can only have one default incoming and one default outgoing sequence flow.

Unlike most BPMN flow objects, the manual task does not enable you to manipulate data objects. Data objects associated with the previous flow element are passed through as is to the next flow element.

A.3.3.1 The Manual Task in Context

In the context of the Sales Quote example, a manual task can be added for printing and signing a copy of a formal contract as shown in Figure A-17.

Figure A-17 Example of a Manual Task

Description of Figure A-17 follows
Description of "Figure A-17 Example of a Manual Task"

In this example, signing the formal contract is something that you may want to explicitly show as part of your business process. However, because it is not managed by the BPMN Service Engine, a manual task is used.

A.3.4 Introduction to the Update Task

The update task is used to perform operation on one or more Human Tasks. For example, you can use the update task perform actions like reassigning a task to another user.

Figure A-18 shows the default notation for the update task.

Figure A-18 The Update Task

Description of Figure A-18 follows
Description of "Figure A-18 The Update Task"

For more information on using the update task see Oracle BPM Modeling and Implementation Guide.

A.4 Communicating With Other Processes and Services

Oracle BPM enables you to define interactions across business processes within a process-oriented application. The following sections describe the BPMN flow objects used to model communication between processes.

This section describes how to use these flow objects to create process models using Business Process Composer. For information on how to implement these flow objects within a process-based application, see the Oracle BPM Modeling and Implementation Guide.

A.4.1 Introduction to the Service Task

The service task enables you to communicate with other processes and services. Process analysts can add the service task when they know that a process must invoke an external service or process.

Process developers can then implement the necessary services. You can use the service task to invoke the following:

  • Other BPMN processes

  • BPEL processes

  • SOA service adapters

  • Mediators that are exposed as services

See Section 5.5.1, "How to Assign a Business Catalog Component to a Flow Object" for information on for procedures on how to assign elements from the business catalog to a service task.

The service task has similar behavior to the send and receive task pair and the message throw and catch event pair. The primary difference is that the service task is used to invoke processes and services synchronously. When the service task invokes a process or service, the token waits at the service task until a response is returned. After the response is received, the token continues to the next sequence flow in the process.

See "Using Service Tasks to Invoke Synchronous Operations in Services and BPMN Processes" in the Oracle BPM Modeling and Implementation Guide for more information on how to implement the service task with these types of processes and services.

Figure A-19 shows the default notation for the service task.

Figure A-19 The Service Task

Description of Figure A-19 follows
Description of "Figure A-19 The Service Task"

A.4.1.1 The Service Task in Context

Figure A-20 shows an example of the service task used to save the finalized sales quote to a database.

Figure A-20 The Service Task within the Sales Quote Example Process

Description of Figure A-20 follows
Description of "Figure A-20 The Service Task within the Sales Quote Example Process"

A.4.1.2 Implementing Reusable Services in Project Templates

Oracle BPM enables you to incorporate reusable services in project templates. These services are components of the business catalog.

A.4.2 Introduction to the Notification Task

The notification task is similar to the service task. It uses a predefined service to perform different types of notification. You can use expressions to determine the users or groups who will receive notifications generated by the notification task.

For more information on implementing the notification task see Oracle BPM Modeling and Implementation Guide.

These different types of notification are:

A.4.3 Introduction to the Call Activity

The call activity allows you to call a reusable process from within the current process. The process being called becomes a child process of the calling process. When calling a reusable process, the call activity of the parent process waits until the child process completes before continuing.

Figure A-26 shows the default notation for the call activity.

Figure A-26 The Call Activity

Description of Figure A-26 follows
Description of "Figure A-26 The Call Activity"

See Section A.9.1, "Introduction to Reusable Processes (Reusable Subprocesses)" for more information.

Data objects of the parent process are not automatically available to the reusable process. Data objects must be passed to and from the child process using argument mapping of the call activity.

A.4.4 Introduction to the Send Task

The send task sends a message to a system or process outside the current process. After this message is sent, the task is complete and running of the process continues to the next task in the process flow.

The send task is frequently paired with the receive task to invoke a process or service and receive a response in return. The send and receive tasks are used to invoke processes and services asynchronously. If you are invoking a process or service synchronously, use the service task.

Note:

The send and receive tasks perform functions similar to the throw and catch message events. However, you cannot use the send task to invoke a process that is initiated with a message start event.

Figure A-27 shows the default notation for the send task.

Figure A-27 The Send Task

Description of Figure A-27 follows
Description of "Figure A-27 The Send Task"

For information on implementing the send task to invoke a process or service, see "Using Send and Receive Tasks to Define a Synchronous Operation in a BPMN Process" in the Oracle BPM Modeling and Implementation Guide.

A.4.4.1 The Send Task in Context

See Chapter A, "Using the Send and Receive Tasks to Communicate Between Processes" for information on using the send and received tasks to communicate between processes.

A.4.5 Introduction to the Receive Task

In contrast to the send task, the receive task waits for a message from a system or process outside the current process. After this message is received, the task is complete and running of the process continues to the next task in the process flow.

Figure A-28 shows the default notation for the receive task.

Figure A-28 The Receive Task

Description of Figure A-28 follows
Description of "Figure A-28 The Receive Task"

For information on implementing the send task to invoke a process or service, see "Using Send and Receive Tasks to Define a Synchronous Operation in a BPMN Process" in the Oracle BPM Modeling and Implementation Guide.

A.4.5.1 The Receive Task in Context

See Section A.4.6, "Using the Send and Receive Tasks to Communicate Between Processes" for information on using the send and receive tasks to communicate between processes.

A.4.5.2 Starting a Process with the Receive Task

You can use the receive task to trigger the start of a process. This is useful when you want to invoke a process from another process using a send task.

To start a process using the receive task, the following conditions must be met:

  • The receive task is preceded by an none start event.

  • Your process does not contain any other start events.

  • The Create Instance property is enabled.

The following section describes how to use the send and receive tasks to communicate between processes.

A.4.6 Using the Send and Receive Tasks to Communicate Between Processes

You can use the send and receive tasks to invoke another BPMN process and receive messages back from it. Processes that begin with a receive task and contain a send task are exposed as services that can be used by other process and services within an Oracle BPM application.

Figure A-29 outlines the basic behavior when using send and receive tasks to invoke a process and receive a response.

Figure A-29 Using the Send and Receive Tasks to Communicate Between Processes

Description of Figure A-29 follows
Description of "Figure A-29 Using the Send and Receive Tasks to Communicate Between Processes"

The following steps outline a possible scenario when using the send and receive tasks to communicate between processes.

  1. Process A is invoked.

  2. A token of Process A reaches the send task.

  3. The send task invokes Process B.

    This is defined by the implementation for the send task.

  4. The token of process A proceeds to the next flow object in the process.

  5. The receive task initiates a process instance of Process B.

    The receive task must have the Create Instance property defined. See Section A.4.5.2, "Starting a Process with the Receive Task.".

  6. The newly created token proceeds through process B.

  7. Depending on the specific behavior of your process, the following scenarios may occur:

    1. If the token of Process A reaches a receive task paired with a send task from Process B, the token of Process A waits until a response is received. After the response is received, the token of Process A continues to the next flow object.

    2. If the token of Process B reaches a send task paired with a receive task in Process A, Process B sends a response to Process A. The token of Process B continues to the next flow object.

  8. Both processes continue running. You can use subsequent send and receive pairs to define subsequent communication between the two processes.

A.4.7 Introduction to the Message Throw Event

The message throw event enables you to send a message to another process or service.

Figure A-30 shows the default notation for the message throw event.

Figure A-30 The Message Throw Event

Description of Figure A-30 follows
Description of "Figure A-30 The Message Throw Event"

The throw message event can be used to invoke the following types of processes and services:

  • Other BPMN processes

  • BPEL processes

  • SOA service adapters

  • Mediators that are exposed as services

Process analysts may add message throw events to a process to define where a process must invoke another process or service. However, process developers are typically responsible for implementing the connectivity with other processes. Additionally, they are typically responsible for creating and implementing the services invoked by the message throw event.

For information on how to implement message throw events, see "Communicating With Other BPMN Processes and Services Using Message Events" in the Oracle BPM Modeling and Implementation Guide.

Message throw events are often used to invoke other BPMN processes by calling the message start event of another process. See Section A.2.4, "Introduction to the Message Start Event" for more information.

Message throw events are also frequently used with message catch events to receive a response from the process or service invoked. However, they are always used asynchronously. After the message throw event sends a message to another process or service, the token immediately moves to the next flow object of the process.

If your process receives a response synchronously, use the service task to invoke the process or service. See Section A.4.1, "Introduction to the Service Task" for more information.

Note:

The send and receive tasks perform functions similar to the throw and catch message events. However, you cannot use the message throw event to invoke a process that is initiated with a message receive task.

A.4.8 Introduction to the Message Catch Event

The message catch intermediate event enables you to receive a message from another process or service.

Figure A-31 shows the default notation for the message catch event.

Figure A-31 The Message Catch Event

Description of Figure A-31 follows
Description of "Figure A-31 The Message Catch Event"

The message catch event is frequently used with the message throw event to communicate with another BPMN process. See Section A.4.9, "Using Message Throw and Catch Events to Communicate Between Processes" for information on how message throw events with message catch event.

For information on how to implement message throw events, see "Communicating With Other BPMN Processes and Services Using Message Events" in the Oracle BPM Modeling and Implementation Guide.

A.4.9 Using Message Throw and Catch Events to Communicate Between Processes

You can use combinations of throw and catch events to invoke and communicate with other BPMN processes. When using a throw event to invoke another process, the following conditions must be met:

  • The process being invoked must be an asynchronous process. Although you can use a message throw event to invoke a synchronous process, there is no mechanism for catching messages synchronously from the process.

    If you invoke a synchronous process use the service task. See Section A.4.1, "Introduction to the Service Task" for more information.

  • The first time you use a message throw event it must be paired to the message start event of the other process. This is required to trigger the process instance. After the instance has been triggered, you can use subsequent message throw events that are caught by the second process.

Processes that begin with a message start and end with a message end event are exposed as services that can be used by other process and services within an Oracle BPM application.

Processes invoked from another process are not considered child processes. This is important to consider when designing processes that use the terminate end event as a process end point. For example, a terminate event in the calling process does not stop processes invoked with a message throw event.

Figure A-32 shows the basic behavior when using message throw and catch events to invoke a process and receive a response.

Figure A-32 Using Message Throw and Catch Events Between Processes

Description of Figure A-32 follows
Description of "Figure A-32 Using Message Throw and Catch Events Between Processes"

The following steps outline a possible scenario when using the message throw and catch events to communicate between processes.

  1. Process A is invoked.

  2. The token of Process A reaches a message throw event that is configured to invoke Process B.

  3. The message throw event sends a message to the message start event of Process B.

  4. The token of Process A proceeds to the next flow object.

  5. The message start event triggers an instance of Process B.

  6. The newly created token proceeds through Process B.

  7. Depending on the behavior of your process, the following scenarios may occur:

    1. If the token of Process A reaches a catch event paired with a throw event from Process B, the token of Process A waits until the message is received. After the message is received, the token of Process A continues to the next flow object.

    2. If the token of Process B reaches a throw event paired with a catch event in Process A, Process B throws a message to Process A. The token of Process B continues to the next flow object.

  8. Both processes continue running. You can use subsequent catch and throw event pairs to define subsequent communication between the two processes.

A.5 Adding Business Logic Using Oracle Business Rules

This section describes how to use the business rule task to incorporate Oracle Business Rules within your business processes. See Chapter 13, "Using Oracle Business Rules" for information on working with Oracle Business Rules using Business Process Composer.

A.5.1 Introduction to Oracle Business Rules

Business rules are statements that describe business policies or describe key business decisions.

A.5.2 Introduction to the Business Rule Task

The business rule task enables you to incorporate Oracle Business Rules within your process.

Figure A-33 shows the default notation for the business rule task.

Figure A-33 The Business Rule Task

Description of Figure A-33 follows
Description of "Figure A-33 The Business Rule Task"

There are two primary use cases for incorporating Oracle Business Rules within your business process.

  • Using structural rules

    Structural rules enable you to perform calculations used within your business process. For example, you can use a business rule to calculate a credit score.

  • Using operative rules

    Operative rules are used to make changes to the flow of your process. A typical use of an operative rule is to perform a check of the rule conditions within the rules catalog. Then, as part of the output data association, assign a value to a data object using an expression.

    In this scenario, the business rule task is immediately followed by a gateway that is used to branch the process path according to the value of the data object.

    See Section A.5.2.1, "The Business Rule Task in Context" for information on how an operation rule is used within the Sales Quote example.

See Section 5.5.1, "How to Assign a Business Catalog Component to a Flow Object" for information on for procedures on how to assign elements from the business catalog to a business rule task.

A.5.2.1 The Business Rule Task in Context

Figure A-34 shows an example of the business rule task within the Sales Quote example.

Figure A-34 The Business Rule Task within the Sales Quote Example Process

Description of Figure A-34 follows
Description of "Figure A-34 The Business Rule Task within the Sales Quote Example Process"

A.6 Controlling Process Flow Using Sequence Flows

This section describes how to use sequence flows to define the behavior of your business process.

A.6.1 Introduction to Sequence Flows

Sequence flows define the order or sequence that work is performed within a process. Sequence flows connect the flow objects within your process and determine the path a process token follows through your process.

Incoming sequence flows are the sequence flows that lead into a flow object. Outgoing sequence flows are the sequence flows that determine the process path out of a flow object.

Most flow objects contain both incoming and outgoing sequence flows. Exceptions to this are start and end events. Start events can only contain outgoing sequence flows. End events can only contain incoming sequence flows. Additionally, event subprocesses do not have either incoming or outgoing sequence flows.

A.6.2 Introduction to Unconditional Sequence Flows

Unconditional sequence flows represent the typical path between two flow objects. Default sequence flows are displayed as a line with and arrow as shown in Figure A-35.

Figure A-35 The Unconditional Sequence Flow

Description of Figure A-35 follows
Description of "Figure A-35 The Unconditional Sequence Flow"

Most flow objects can contain only one default out going sequence flow. Only parallel gateways can contain multiple unconditional sequence flows which represent the parallel paths of your process.

Exclusive, inclusive, and conditional gateways cannot have unconditional outgoing sequence flows. These gateways use conditional and default sequence flows to determine the flow of your process.

A.6.3 Introduction to Conditional Sequence Flows

Conditional sequence flows are used to control the flow of a process based on certain conditions. Like unconditional sequence flows, conditional sequence flows are displayed by an arrow lined arrow.

Figure A-36 shows two outgoing conditional sequence flows and a default sequence flow.

Figure A-36 Conditional and Default Sequence Flows

Description of Figure A-36 follows
Description of "Figure A-36 Conditional and Default Sequence Flows"

Not all flow objects can use outgoing conditional sequence flows. Only the following types of gateways can have outgoing conditional sequence flows:

  • Exclusive gateways

  • Inclusive gateway (split)

The conditions used within a conditional sequence flow are defined using expressions. See Section 12.7, "Introduction to Expressions" for information on using the expression editor to define expressions.

A.6.4 Introduction to Default Sequence Flows

Like conditional sequence flows, default sequence flows are used as outgoing sequence flows to exclusive, inclusive, and conditional gateways. Default sequence flows represent the path your process will take out of these gateways when none of the conditions evaluate to true.

Default sequence flows are represented by an arrowed line with a tic mark on one end as shown in Figure A-36.

A.7 Controlling Process Flow Using Gateways

This section describes how to use gateways to control process flow and behavior.

A.7.1 Introduction to Gateways

Gateways are flow elements that define the flow of your process. Gateways determine the path a token takes through a process. They define control points within your process by splitting and merging paths.

When possible, gateways are used for paths that are exceptions to or deviate from the default path of the process.

A.7.1.1 Split-Merge Pairs

The following gateways require a split-merge pair:

  • Parallel gateway

  • Inclusive gateway

  • Complex gateway

When you add one of these gateways to a BPMN process, Oracle BPM Studio automatically creates the split and merge flow objects.

Although the merge portion of the gateway is required, you do not have to ensure that all paths out of the split return to the merge.

Although it is possible to have process paths that split at a gateway without merging through the gateway, this is not usually good practice. For more details on the merge behavior of gateways, see the following sections for each gateway type.

Note:

If you delete the merge gateway from a process, the corresponding split gateway is also deleted.

A.7.2 Introduction to the Exclusive Gateway

The exclusive gateway enables you to split your process into two or more paths. However, the process only continues down one of these paths even if multiple outgoing sequence flows are present. Exclusive gateways can have conditional outgoing sequence flows and must have at least one default outgoing sequence flow.

You can define expressions that are used to determine if your process continues down a conditional sequence flow. See Section 12.7, "Introduction to Expressions" for more information.

If your process has multiple outgoing sequence flows for an exclusive gateway, you can define the order in which they are evaluated. The order of evaluation is configured in the properties of the exclusive gateway.

If you have an exclusive gateway where more than one conditional evaluates to true, the process will continue down the first conditional sequence flow determined by this order.

Unlike other gateways, the exclusive gateway does not require a corresponding merge to be explicitly defined in your process after splitting.

Figure A-37 shows the default notation for the exclusive gateway.

Figure A-37 The Exclusive Gateway

Description of Figure A-37 follows
Description of "Figure A-37 The Exclusive Gateway"

A.7.2.1 The Exclusive Gateway in Context

Figure A-38 shows an example of the exclusive gateway used within the Sale Quote example. Here, the exclusive gateway is used to evaluate whether a review of business practices is required.

Figure A-38 The Exclusive Gateway within the Sales Quote Example Process

Description of Figure A-38 follows
Description of "Figure A-38 The Exclusive Gateway within the Sales Quote Example Process"

This evaluation is determined by the expression defined for the outgoing conditional sequence flow. If this evaluates to true, then the process flow proceeds down the Yes path. If it evaluates to false, then the process flow proceeds down the path of the default outgoing sequence flow.

A.7.2.2 Splitting and Merging Exclusive Gateways

When a token reaches an exclusive gateway the outgoing conditional sequence flows are evaluated until one of them evaluates to true. You can define the specific order in which these are evaluated by configuring a property for the exclusive gateway.Based on this configuration, when the first conditional sequence flow evaluates to true, the token moves down this outgoing sequence flow to the next flow object. If you have multiple outgoing conditional sequence flows, you can determine the order in which they are evaluated.If none of the outgoing conditional sequence flows evaluate to true, then the token moves down the default outgoing sequence flow. Therefore, you must define a default outgoing sequence flow for the exclusive gateway.

The exclusive gateway can also merge incoming sequence flows. However, there is no synchronization with other tokens that may be coming from other paths within the process flow.

Note:

If other tokens arrive at an exclusive gateway merge, then they are also passed through as is. If you are synchronizing tokens or perform evaluations on incoming sequence flows, you should use a different type of gateway.

A.7.3 Introduction to the Inclusive Gateway

The inclusive gateway enables you to split your process into two or more paths. Unlike the exclusive gateway, however, a token may flow down one or more of these paths depending on how the outgoing conditional sequence flows are evaluated.

You must define at least one default sequence flow for the inclusive gateway split. You can have multiple outgoing conditional sequence flows for an inclusive gateway split. The token will proceed along only those sequence flows that evaluate to true. If none of the sequence flows evaluate to true, then the token passes along the default sequence flow.

Figure A-39 shows the default notation for the inclusive gateway split.

Figure A-39 The Inclusive Gateway (Split)

Description of Figure A-39 follows
Description of "Figure A-39 The Inclusive Gateway (Split)"

Figure A-40 shows the default notation for the inclusive gateway merge.

Figure A-40 The Inclusive Gateway (Merge)

Description of Figure A-40 follows
Description of "Figure A-40 The Inclusive Gateway (Merge)"

A.7.3.1 Splitting and Merging Inclusive Gateways

The inclusive gateway splits a process similar to the exclusive gateway, but enables tokens to proceed down multiple outgoing sequence flow. When a token arrives at an inclusive gateway, the expressions of its conditional sequence flows are evaluated.

Next, a token is generated for each of the conditional sequence flows that evaluates to true. A token is generated for the default sequence flow only if none of the conditional sequence flows evaluates to true.

These tokens are joined at the merge of the inclusive gateway. When a token reaches the merge gateway, it waits until all of the tokens generated by the split have reached the merge. After all of the tokens have reached the merge of the inclusive gateway, the merge is complete, and the token continues to the next sequence flow after the gateway.

A.7.4 Introduction to the Parallel Gateway

The parallel gateway enables you to split your process into two or more paths when you want your process flow to follow all paths simultaneously. The parallel gateway is useful when your process must perform multiple tasks in parallel.

Figure A-41 shows the default notation for the parallel gateway split.

Figure A-41 The Parallel Gateway (Split)

Description of Figure A-41 follows
Description of "Figure A-41 The Parallel Gateway (Split)"

Figure A-42 shows the default notation for the parallel gateway merge.

Figure A-42 The Parallel Gateway (Merge)

Description of Figure A-42 follows
Description of "Figure A-42 The Parallel Gateway (Merge)"

A.7.4.1 The Parallel Gateway in Context

The Sales Quote example uses a parallel gateway during the approval stage of the process. Figure A-43 shows how the parallel gateway is used to perform two process paths simultaneously.

Figure A-43 Example of a Parallel Gateway

Description of Figure A-43 follows
Description of "Figure A-43 Example of a Parallel Gateway"

In this example, two different process paths are executed at the same time.

A.7.4.2 Splitting and Merging Parallel Gateways

When a token reaches a parallel gateway, the parallel gateway creates a token for each outgoing sequence flow. The split of the parallel gateway does not evaluate outgoing sequence flows.

You can also use the parallel gateway to merge process paths split by the parallel gateway. The merge of the parallel gateway waits for a token to arrive from each of the incoming sequence flows. After all tokens arrive, only one token is passed to the outgoing sequence flow.

Note:

Design your process so that a token arrives for each incoming sequence flow for the merging parallel gateway. If you do not, your process can freeze if the merge is expecting tokens that do not arrive.

A.7.5 Introduction to the Complex Gateway

The complex gateway splits a process similar to an inclusive gateway. However, it enables you to define an activation condition that determines if the instance can continue even if not all of the tokens have arrived at the complex gateway merge.

For example, you can configure a complex gateway to continue after two or more tokens have arrived. If only two out of the possible conditions in the inclusive gateway evaluate to true the process instance continues to the next activity. However because the inclusive gateway immediately evaluates all the conditional sequence flows, all of the flow objects in these process paths are also run.

Figure A-44 shows the default notation for the complex gateway split.

Figure A-44 The Complex Gateway (Split)

Description of Figure A-44 follows
Description of "Figure A-44 The Complex Gateway (Split)"

Figure A-45 shows the default notation for the complex gateway merge.

Figure A-45 The Complex Gateway (Merge)

Description of Figure A-45 follows
Description of "Figure A-45 The Complex Gateway (Merge)"

A.7.6 Introduction to the Event-based Gateway

The even-based gateway enables you to branch your process flow based on the possibility that an event may occur. Depending on the context, this may be one of several types of events.

The event-based gateway enables you to anticipate the possibility that several types of events may occur at a specific point in your process. It is similar to the exclusive gateway, but instead of choosing a path based on expressions, the event-based gateway chooses a path based on the occurrence of an event within your process.

For example, in an order processing process, you may reach a point in your process when there is no stock currently available. The process may need to wait until stock is available, but cannot wait indefinitely. By using an event-based gateway, your process can wait for a message saying new stock has been received (using a message catch event) or it can continue if no message is received after a certain amount of time has passed (using a timer event).

Figure A-46 shows the default notation for the event-based gateway.

Figure A-46 The Event-based Gateway

Description of Figure A-46 follows
Description of "Figure A-46 The Event-based Gateway"

The event-based gateway is different from other gateways in that decisions about process flow are based on an event rather than data-specific conditions.

The event-based gateway is composed of the following:

  • The event-based gateway

  • Two or more target events. These can be of the following types:

    • Message catch events

      When initiating a process using a message catch event, the process must be invoked using a message throw event.

    • Timer catch events

      Generally only one timer event is used following an event-based gateway.

    • Receive tasks

      You can use the receive task to initiate a process instance following an event-based gateway. However the process must be invoked from a send task within the calling process.

    Note:

    You cannot mix message events and receive tasks within the same event-based gateway.

The target elements can only have incoming sequence flows from the event-based gateway. They cannot have sequence flows from other parts of the process.Although the event-based gateway enables you to plan that multiple events may occur in your process, within the process instance, only one event is triggered. When the first event in the event-based gateway is triggered, the path that comes after that event is followed.

By default, when you add an event-based gateway to a process, it is created with a timer and message catch event.

Note:

If you delete an event-based gateway, any outgoing sequence flows are also deleted. The associated events are not deleted.

A.7.6.1 Starting a Process with an Event-Based Gateway

You can also use an event-based gateway at the beginning of a process to create a new process instance. This is similar to having multiple start events within a process.

To enable an event-based gateway to create a new process instance, you must ensure the following:

  • You have enabled the Initiate property of the event-based gateway.

  • There are no incoming sequence flows to the event-based gateway.

Although the event-based gateway can be used to create a new process instance, it does not accept data input from another process. Any data that must be passed to the process instance must be configured using the target events.

A.8 Controlling Process Flow Using Intermediate Events

This section describes intermediate events and describes how to use them to control the flow and behavior of your process.

A.8.1 Introduction to Intermediate Events

Unlike start and stop events, intermediate events occur during the flow of your process.

There are two types of intermediate events:

  • Normal flow events

    Normal flow events occur within the typical flow of your process.

  • Boundary events

    Boundary events trigger an interruption with your process. Boundary events are associated with flow objects and can be configured to interrupt their usual behavior.

    Boundary events behave similar to sequence flows in that they are used to determine the path a process takes between flow objects.

    Boundary events can be divided into two types: interrupting and non interrupting.

A.8.2 Introduction to the Timer Catch Event

Timer catch events enable you to control the flow of your process using a time condition. Possible uses of the time catch event include:

  • Creating a delay before running an activity

  • Configuring a deadline for an activity

  • Configuring a deadline for a process

  • Triggering additional activities after an elapsed time

Figure A-47 shows the default notation for the timer catch event.

Figure A-47 The Timer Catch Event

Description of Figure A-47 follows
Description of "Figure A-47 The Timer Catch Event"

You can use timer events as boundary events on an activity. Timer events can be defined as either interrupting or non interrupting boundary events.

When an interrupting timer event fires, the token leaves the main process flow to follow the flow the timer event defines. The flow that an interrupting timer event can return directly to the main process flow.

When a non interrupting event fires, a copy of the token is created and passes through the flow the timer event defines. The flow that a non interrupting event defines cannot return to the main process flow.

A.8.3 Introduction to the Error Catch Event

Error catch events are intermediate events used to handle an error that occurs within your process flow.

Note:

You can also use inline handlers to handle error conditions that occur within your process.

Error catch events are always used as boundary events and can be attached to the following:

  • Service Tasks

  • Call Activities

  • User Tasks

  • Send Tasks

  • Receive Tasks

  • Script Tasks

  • Rules Tasks

  • Subprocesses

Error catch events are always interrupting, meaning that they interrupt the usual flow of a process.

Figure A-48 shows the default notation for the error catch event attached as a boundary event on a service task.

Figure A-48 The Error Catch Event as a Boundary Event on a Service Task

Description of Figure A-48 follows
Description of "Figure A-48 The Error Catch Event as a Boundary Event on a Service Task"

When a service or process fails with an error, the error catch event is triggered. This causes the process flow to follow the path of the outgoing sequence flow of the error catch event.

You can use this flow to define how you handle the error. This is handled in two ways:

  • The process flow returns to the main process flow. Any work that must be performed is handled within the error process flow before returning to the main flow.

    Note:

    If the boundary event is non-interrupting, the boundary flow cannot return to the main flow.

  • The process flow continues to an end event. The process is stopped immediately. Process control is returned to the service or process that initiated the process.

A.9 Using Subprocesses in Oracle BPM

You can use subprocesses to organize you business processes. Subprocesses enable you to group functional areas of your process together and also make your processes more readable.

Oracle BPM supports the following types of subprocesses:

A.9.1 Introduction to Reusable Processes (Reusable Subprocesses)

Oracle BPM supports a type of process called reusable processes. In BPMN terminology, this is sometimes referred to as a reusable subprocess. Reusable processes allow you to create processes that can be called from other BPMN processes.

Reusable processes allow you to create processes that can be called from other BPMN processes. For example all your processes may need to charge a credit card, so you can create a charge credit card reusable subprocess

Reusable processes have the following characteristics:

  • Must start with one none start event

  • Can contain multiple end events.

  • Can only be called by other BPMN processes.

A.9.2 Introduction to Embedded Subprocesses (Inline Subprocesses)

Embedded subprocesses enable you to group BPMN flow objects together to make your process more readable. In Oracle BPM, subprocesses are embedded subprocesses. Subprocesses are contained as part of the parent subprocess. Embedded subprocesses must begin with a start none event and must end with a none end event.

Embedded subprocesses can be expanded or collapsed. Figure A-49 shows how a collapsed subprocess appears within a process.

Figure A-49 Example of a Collapsed Embedded Subprocess

Description of Figure A-49 follows
Description of "Figure A-49 Example of a Collapsed Embedded Subprocess"

Figure A-50 shows how an expanded embedded subprocess appears within a process. When an embedded subprocess is expanded, you can edit the flow objects within it. You can also click and drag the edge of the embedded subprocess window to make the window larger or smaller.

Figure A-50 Example of an Expanded Embedded Subprocess

Description of Figure A-50 follows
Description of "Figure A-50 Example of an Expanded Embedded Subprocess"

Similar to other types of processes, embedded subprocesses have can contain start and end events and contain a separate process flow. An embedded subprocess must begin with a none start event and end with a none end event. Embedded subprocesses cannot contain swimlanes.

Embedded subprocesses also behave similar to activities. They can have incoming and outgoing sequence flows. They also contain data associations that define the data objects used within the embedded subprocesses.

Embedded subprocesses can also contain timer, message, and error boundary events.

If necessary, your process can contain nested embedded subprocesses. However, use nested embedded subprocesses only when necessary to make your process more readable.

A.9.2.1 Embedded Subprocesses and Sequence Flows

The flow objects within an embedded subprocess cannot have sequence flows that connect to flow objects outside the subprocess.

Similar to other flow objects, embedded subprocesses have incoming and outgoing sequence flows.

A.9.2.2 Embedded Subprocesses in Context

Figure A-51 show an example of a embedded subprocess. In this example, an embedded subprocess is used to group the service task used to process a sales quote.

Figure A-51 Example of an Embedded Subprocess

Description of Figure A-51 follows
Description of "Figure A-51 Example of an Embedded Subprocess"

A.9.2.3 Looping Embedded Subprocesses

You can configure a subprocess to repeat numerous times within the context of a process flow. This is something that a process analyst should consider when designing a process, but the implementation is performed by process developers.

Note:

Looping cannot be configured using Oracle Business Process Composer. You must used Oracle BPM Studio to configure the looping property of an embedded subprocess. See the Oracle BPM Modeling and Implementation Guide for more information.

A.9.3 Introduction to Event Subprocesses (Event Handlers)

Event subprocesses are a type of subprocesses that enable you to model possible conditions that happen outside of a normal process flow. Event subprocesses are also called event handlers.

Event subprocesses can have the following start events:

  • Error start

  • Timer start

  • Message start

When you add an inline handler to your process, by default it is created with a message start event. You can change the type of start event if necessary.

Note:

Inline handlers can only contain one start event. However, you can have multiple inline handlers within your process.

A.10 Changing the Value of Data Objects in Your Process

This section describes how to use the script task to change the values of data objects within your process. See Chapter 12, "Handling Data in Your Business Processes" for general information about data objects.

A.10.1 Introduction to the Script Task

The script task is used to change values of data objects within your process. The script task is used when you want to show this change explicitly within your business process or when you must change the values of data objects outside of another flow object. It is often used to set initial values of data objects at the beginning of a process.

Figure A-52 shows the default notation for the script task.

Figure A-52 The Script Task

Description of Figure A-52 follows
Description of "Figure A-52 The Script Task"

Script tasks are added to a process by process developers who are responsible for defining the behavior of data objects within a process and process-based application.

A.10.1.1 The Script Task in Context

Figure A-53 shows two examples of the script task used at the beginning of the Sales Quote example. The Sales Quote example uses a script task to set initial values for data objects when the process instance is created and to set values for several business indicators.

Figure A-53 The Script Task within the Sales Quote Example

Description of Figure A-53 follows
Description of "Figure A-53 The Script Task within the Sales Quote Example"

Project data objects are data objects that you define in a project. All processes within a project have access to the data object defined, though the value changes according to the process using them. In addition, the engine stores the value of those marked as business indicators to the process analytics databases if the project is configured to use them.

Figure A-54 shows the data associations used to set initial values for the business indicators.

Figure A-54 Data Associations Used by the Set Business Indicators Script Task

Description of Figure A-54 follows
Description of "Figure A-54 Data Associations Used by the Set Business Indicators Script Task"

As with other flow objects that accept data associations, you can use expressions to change the values of data objects. Figure A-55 shows how an expression is used to change the value of the discount project variable.

Figure A-55 Expression Used to Change the Value of Discount Project Variable

Description of Figure A-55 follows
Description of "Figure A-55 Expression Used to Change the Value of Discount Project Variable"

Note:

If you implemented the script task using transformations using BPM Studio, they will not be visible when opening the BPM project in Business Process Composer.