| Oracle® Business Process Architect Quick Start Guide Release 10.1.3.3 E10030-01 |
|
 Previous |
 Next |
| Oracle® Business Process Architect Quick Start Guide Release 10.1.3.3 E10030-01 |
|
Previous |
Next |
Oracle BPA Suite contains over fifty model types for modeling business processes, business data, business services and organizational structure. Filters are an effective way to customize as well as to tone down the number of model types and the objects within the model type exposed to the user. Filters can be used to create different views for different sets of business users. Filters can be easily created, modified, exported and imported using the Filter wizard. Use online help in the Business Process Architect for usage information on the Filter wizard. Oracle BPA Suite is prepackaged with set of filters and "Oracle BPA Method" is one such filter. It contains a subset of model types such as BPMN, EPC and includes Oracle SOA modeling objects for rich BPEL code generation from the Business Process Diagrams.
Oracle has extended the modeling objects present in the underlying ARIS product to better integrate with Oracle SOA Suite. The ARIS EPC and BPMN method types have been extended to include Automated activity, Human workflow activity, Notification activity and Business Rules activity. Automated activity represents interaction with a system and refers to a Business Service, it's input and output. Business processes often require human interactions as well. The users who participate in the business process have roles and privileges to perform tasks in the business process. The Human workflow activity represents the human/manual tasks.
Notifications are sent to alert users of changes to the state of a task. Notifications can be sent through any of the following channels: e-mail, telephone voice message, fax, pager, or SMS. This is captured by the Notification Activity.
Business rules are statements that describe the policies of a company.A business rule engine is a system that manages and executes business rules. A business rule system typically consists of a rule repository, rule author, and rule engine. The rule author allows business rules to be specified separately from application code. Separating the business rules from code allows business analysts to change business policies quickly with graphical tools. The rule engine evaluates the business rule and returns decisions or facts that are then used in the business process. The rules are typically stored in a rule repository in a database or file system. The Business Rule activity in the Oracle BPA Modeling tool is used to point to the Business Rule defined using the Rules Editor of a Rules Engine.
As well as the standard elements available on Business Process Modeling Notation (BPMN) diagrams, you can also add automated activities, human tasks, notification activities, and business rules.
|
Note: With the following elements, the Business View tab in the various property dialogs contains editable fields for the business analyst to add details of the various elements. The IT View is the implementation detail, which is editable in JDeveloper, but read-only in Oracle BPA. |
These are activities executed automatically by the system.
|
Note: The Automated activity can represent either an invocation of a Business Service or the receipt of a business event from a Business Service. |
Properties of automated activities are as follows:
Standard Properties - Automated Activity
Name - Enter a unique name for the automated activity.
Represented by - Select how you want to represent the activity:
Empty - No other details can be specified for this activity.
Abstract BPEL activity - Select to specify that it is not known whether the automated activity is an "invoke service" versus "receive event" type.
Invoke - Select to specify that the automated activity invokes the Business Service.
Receive - Select to specify that the automated activity receives event from a Business Service.
Service name - Represents a Business Service. Enter the name of the Business Service or select an existing Business Service. The Business Services are browsed from the IT systems models. The Business Services can be linked to a concrete WSDL.
Input - Represents the Input message of the Business Service. It is a Business Data. Enter the input (as free text) or select items from a Data Model in the project. The Business Data can also be linked to a UML class and concrete XSD.
Output - Represents the Output message of the Business Service. Output is Business Data. Enter the output (as free text) or select items from a Data Model in the project. The Business Data can also be linked to a UML class and concrete XSD.
Standard Properties - Sensor definition
|
Note: This defines BPEL Sensors that enable you to monitor BPEL process activities, variables, and faults during runtime. Sensor definitions becomes probes in the executable business process and send data to Business Activity Monitoring dashboards. |
When to watch - Select from "At the beginning", "At the end", or "Exception".
What to watch - Variables separated by commas.
Action - Enter a description (in free text) of the action taken by this BPEL Sensor when the watch conditions are met.
Extended Properties
Description - Free text field. This appears as annotation in the corresponding scope upon BPEL transformation.
Tasks performed by individuals rather than systems. Properties of human tasks are as follows:
Standard Properties - Human task
Name - Enter the name for the human task.
Description/Definition - Free text. This appears as annotation in the corresponding scope upon BPEL transformation.
Priority -Enter the priority number for the task. Priority can be 1 through 5, with 1 being the highest. By default, the priority of a task is 1.
Expiration -Enter expiration duration for the human task. If the user does not act on the task before the expiration duration has been reached, the task will be escalated to the manager for further action.
Standard Properties - Assignee
<name field> - Click Add to enter or select the title of the person or persons assigned the task in the Assignees dialog, in which you can set the following:
Workflow pattern - Select the participant type you require for the assignee or assignees.
Single approver - This participant type requires a single user to act on a task. If the task is assigned to a role or group with multiple users, one of the members must claim the task and act on it. Based on the user's action, you define what the business process does.
Group vote - Used when multiple users, working in parallel, must take action simultaneously, such as in a hiring situation when multiple users vote to hire or reject an applicant. You specify the voting percentage that is needed for the outcome to take effect, such as a majority vote or a unanimous vote.
Management chain - Routes tasks for approval to multiple users in a management chain hierarchy. You specify the task participants as a management chain list or a list of users.
Sequential list of approvers - Enables you to create a list of sequential participants for a workflow. For example, if you want a document to be reviewed by John, Mary, and Scott in sequence, use this participant type. This is similar to the management chain participant type, except that with that type, the users are part of an organization hierarchy. For the sequential list of approvers participant type, they can be any list of users or groups.
FYI assignee - Used when a task is sent to a user, but the business process does not wait for a user response; it just continues. FYI assignees cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.
External routing service - Enables you to configure an external routing service that dynamically determines the participants in the workflow. If this participant type is specified, all other participant types are ignored. It is assumed that the external routing service provides a list of participant types (single approver, list of approvers, group vote, and so on) at run time to determine the routing of the task.
Assignees - Enter or select the roles of the assignees.
Remark - Enter a comment (in free text) to describe this assignment.
|
Note: It is recommended that instead of creating a new assignee in this field, add the new assignee to the Organizational chart, then return to this property and select the assignee from the list of available items listed in the Organizational chart. |
Extended Properties - Human task
Title - Enter the title for the human task. The title is displayed as the task in the Oracle BPEL Worklist Application at run time.
Notification/Reminder - Enter instructions to specify the notification/reminder used by business users. Notifications indicate when a user is assigned a task, or informed that the status of the task has changed. Task reminders are sent either at the time the task was assigned to a user, or at the expiration time of a task. The number of reminders and the interval between the reminders can also be configured.
Allow participants to invite others - Ad hoc routing of tasks.
Owner -Enter or select the role who owns the task. You can either enter the role as free text, or select roles from the organizational chart.
Task parameters -Enter business data items to be used as the task parameters.
Attachment -Enter the name of the attachment(s) to be used as part of the human task. For example a checklist or sign-off document.
Extended Properties - Restricted actions
These are actions the assignee is prohibited from doing. Select from:
Show
Withdraw
Delegate
Escalate
Request information
Push back
Reassign
Suspend
Issues a notification. Properties of notification activities are as follows:
Standard Properties - Notification
Name - Enter the name of the notification activity.
Channel -Select from "Email", "Fax", "Pager", or "SMS".
Receiver - Enter or select who will receive the notification.
Subject - Enter the subject line to be used in the notification.
Text - Enter the message text to be used in the notification.
Standard Properties - Sensor Definition
|
Note: This defines BPEL Sensors that enable you to monitor BPEL process activities, variables, and faults during runtime. Sensor definitions becomes probes in the executable business process and send data to Business Activity Monitoring dashboards. |
When to watch - Select from "At the beginning", "At the end", or "Exception"
What to watch - Variables separated by commas.
Action - Enter a description (in free text) of the action taken by this BPEL Sensor when the watch conditions are met.
Extended Properties - Notification
Description/Definition - Enter a description for the notification activity.
CC - Enter a valid e-mail account to be copied with this notification message.
BCC - Enter a valid e-mail account to be blind copied with this notification message.
Reply to- Enter a valid e-mail account to be used in the Reply To field for this notification message.
From - Defaults to the account used to send system notifications or enter a custom account from which to send the notification message.
Attachment -Enter the name of the attachment(s) to be sent with the notification.
Defines the behavior of the business process. A business rule engine is a system that manages and executes business rules. A business rule system typically consists of a rule repository, rule author, and rule engine. The rule author allows business rules to be specified separately from application code. Separating the business rules from code allows business analysts to change business policies quickly with graphical tools. The rule engine evaluates the business rule and returns decisions or facts that are then used in the business process. The rules are typically stored in a rule repository in a database or file system.
Properties of business rules are as follows:
Standard Properties - Business rule function
Name - Enter the name for the business rule.
Rules - Enter the description that defines the Business Rules set.
Standard Properties - Input (facts)
Enter (free text) the business data to be the inputs for the business rule, or select business data identified in the Data Models.
Standard Properties - Output (watch)
Enter (free text) the business data to be output by the business rule, or select business data identified in the Data Models.
Standard Properties - Sensor Definition
|
Note: This defines BPEL Sensors that enable you to monitor BPEL process activities, variables, and faults during runtime. Sensor definitions becomes probes in the executable business process and send data to Business Activity Monitoring dashboards. |
When to watch - Select from "At the beginning", "At the end", or "Exception".
What to watch - Enter a description (in free text) of which items of Business Data need to be monitored.
Action - Enter a description (in free text) of the action taken by this BPEL Sensor when the watch conditions are met.
Extended Properties - Business rule function
Description/Definition -Enter a description of the business rule function.
Data structures in Oracle BPA can be imported from XSD files.
Select a folder under a database node in the Explorer tree in Designer pane.
Select SOA > Import data structures from the main menu to display the Description of the data structures dialog.
Enter or select the XSD URL containing the definitions for the data structures.
Enter or select the Target group into which you want to import the data structures.
Select Generate in group of the XSD target namespace to automatically create the group for the data structures based on the namespace in the XSD file, or select Generate in group and enter or select the group.
Click Finish.
To make a blueprint available for use in the Blueprint Editor in JDeveloper, while viewing or editing an EPC or BPMN diagram in Oracle BPA select SOA > Share with IT.
The blueprint can now be used to create a BPEL process in JDeveloper. For more information on using the Blueprint Editor in JDeveloper, see Chapter 6 - Using Process Blueprints in JDeveloper.
BPEL transformation generates Process Blueprint and associated skeletal BPEL code. The IT developer needs to add implementation details to the BPEL code to convert it into an executable process that can be deployed on the run-time engine (BPEL Process Manager).
The transformation a business process into a BPEL process comprises the following:
Notification Services are transformed into a Business Scope upon BPEL transformation. The corresponding Notification service as well as the BPEL artifacts for invoking the Notification service are created within the business scope.
Human tasks are converted to a human workflow business scope upon BPEL transformation. The Task Service gets automatically generated as well as the BPEL artifacts for invoking the Task service also gets generated. The Notification/Reminder notes get translated to business annotations.
Automated activities are converted to a business scope upon BPEL transformation.
Business Service is converted to a Partner Link upon BPEL transformation. If the Business Service is associated with a concrete WSDL, it is converted to a concrete Partner Link. Otherwise it is converted into an abstract Partner Link. If Represented by is set to "invoke", an invoke activity is created inside the business scope and is linked to the Partner Link. If Represented by is set to "receive", a receive activity is created inside the business scope and is linked to the Partner Link. The Sensor definition is converted in to a business annotation.
XOR, AND and OR gateways are converted to switch and case statements upon BPEL transformation.
All Business Data in the Business Process Diagram are converted to Variables upon BPEL transformation. If the Business Data is associated with an XSD, the XSD is exported and the Variable in the BPEL skeletal process generated is then set to the XSD type. Otherwise, the Variables are set to String type.
Business Rules are converted into a Decision Service. The free text in the Rules field is converted into business annotation.
