Oracle BPM 11g Lesson 2

Oracle BPM 11g Developer Lesson -2
Name – Rakesh Gujjarlapudi

Email Address – rakesh_gujj@yahoo.com

COMPLETE PROCESS IMPLEMENTATION OVERVIEW
The second day workshop will focus on the full process implementation of the Permit Process. We will play the
role of the Process Developer and implement the process by defining Human Task Services, System Services,
Business Rules, Conditional Logic, Script Tasks and binding them to the process activities. We will also generate
and customize User Interface Forms. Lastly, we will deploy the BPM process to the BPM Suite’s runtime engine.

In all of these implementation activities, you will be leveraging declarative tools from the Oracle Fusion
Middleware SOA Suite to design and construct the required logic without having to do any custom coding.

 Human Task Implementation – Defining the human workflow task configuration for each interactivity
activity in the process. You will use the Oracle SOA Suite Human Workflow component to define your
tasks.

 Service Task Implementation – Utilizing web services to integrate with back end services such as a
zoning information system and a payment database system. We will use the Oracle SOA Suite Database
Adapter to generate database operation services. We will also use the Oracle SOA Suite Transformation
Tools to declaratively transform the permit data object to the database structure.

 Business Logic Implementation – Defining a decision table to determine how to process permit
applications. You will use the Oracle SOA Suite Business Rules component to create this decision table
exposed as a decision service. We will also define the conditional expressions to control the process
flow logic and a script task to initialize the process data objects.

 Business Activity Monitoring Implementation – Defining business indicators in the process and enabling
the use of Oracle Business Activity Monitoring (BAM).

 User Interface Forms Generation and Customization – Generating user task forms for each human task
and customizing the generated form to improve the end user interaction. The generated task forms are
based on the Oracle Application Development Framework (ADF). We will be utilizing Oracle ADF
components for customizing the task forms.

 Process Deployment - Mapping the process roles to the actual roles that these users are assigned to in a
Corporate Directory/LDAP Server and then deploying the process to the BPM/SOA runtime environment
running on Oracle WebLogic Suite. For this workshop, we will use the Oracle WebLogic Embedded LDAP
server for the users and groups. All the users and their corresponding groups have already been defined
in the Oracle WebLogic Embedded LDAP Server.

LESSON 6 – HUMAN TASK IMPLEMENTATION
Implement the Human Tasks for each interactive activity. Interactive activities are the ones with the green
boxes.

IMPLEMENTING THE INITIATOR TASK FOR PERMIT APPLICATIONS
Implement the Apply for Permit task. Since this is the first user task, this will initiate the process. We will utilize
the Initiator pattern.

1. Start Oracle BPM Studio by clicking on the BPM Studio icon from the desktop. When prompted to select
a role, select Default Role and click OK.

2. Open the application that you previously modelled in Lesson 1 & 2.
From the Application menu, select Open and navigate to
/home/oracle/workspace/PermitApplication and open the file PermitApplication.jws.

From the BPM Project Navigator, expand the PermitProject > Process folder. Double click PermitProcess.
You should now see the Permit Process diagram in Oracle BPM Studio.

Double-click the Apply for Permit task and click on the Implementation tab. Click the icon to the
right of where it says Human Task.

Name the task PermitApplicationTask and select the Initiator pattern. Give it a Title of Permit
Application.

Define the input parameter for the Human Task. For this lesson, we will import an XML Schema
Definition file called PermitApplication.xsd and use this to create a business object for our input
parameter. For reference, you will find this file in the directory
/home/oracle/MyFiles/Implementation/PermitApplication.xsd.

3. To add an Input Parameter, click the green + icon to the right of where it says Parameters.

We will need to create a Data Object for our Input Parameter. From the Browse Data Objects that
appears, right click on Data Objects under PermitProcess and select Add.

Call the data object PermitApplication and choose the type <Component>. We will create a new
Business Object component based on an XML Schema to define the PermitApplication data object. Click
the icon to browse for a business object to use.

From the component list, click the icon to create a new Business Object.

Name the Business Object PermitApplicationObject and specify MyObjects as the Destination Module.
Check the Based on External Schema option to associate the object with an XML Schema. Click the
icon to browse for XML Schema elements.

The Type Chooser window will show up with an empty Project Schema Files folder. We will need to

import the PermitApplication.xsd file from the file system. Click on the icon to locate the XSD file.

Click the icon to browse the file system.

The PermitApplication.xsd file is located in the directory /home/oracle/MyFiles/Implementation. Locate
the file and click OK.

Make sure the Copy to Project option is checked and click OK. When asked if you want to maintain the
original directory structure, just click OK again to accept the default value.

Click OK when asked to Localize Files.

From the Type Chooser, you can then select the PermitApplication element. Click OK.

Click OK to create the business object.

When asked to create the MyObjects module, click Yes.

You can now select the PermitApplicationObject from the component list.

Click OK to create your PermitApplication data object.

Drag the PermitApplication to your Human Task’s parameter table and check the Editable option as
shown. This will make the Permit Application accessible and updatable from the Apply for Permit task.
Click OK.

On the Review Apply for Permit Human Task properties, enter the title Permit Application Data Entry.
Click the Data Association link.

4. Because we will also be using the Apply for Permit task for the user to re-renter any rejected
information, we will need to pass the Permit Application back to the task. Drag the PermitApplication
from the list of data objects from the right to the permitApplication Input field on the left.

Click OK and OK again to complete Apply for Permit human task implementation and go back to the
BPM Process diagram.

IMPLEMENTING THE SIMPLE USER TASK FOR PERMIT REVIEWS
Let’s implement the Review Site Information and Review Plans tasks. We will create a simple human task
definition that will be re-used for both these tasks.

1. From the BPM Process, double-click the Review Site Information task and click on the
Implementation tab. Click the icon to the right of where it says Human Task.

Name the task PermitReviewTask and leave it with the default Simple pattern. Give it a Title of Permit
Review.

Click the Green + icon to the right of where it says Parameters to assign the data object.

In Browse Data Objects, you should see the PermitApplication you defined earlier. Drag the
PermitApplication to your Human Task’s parameter table. This will make the Permit Application
accessible from the Permit Review task. Click OK.

As shown above, the Permit Review task is defined using the default Simple pattern and can return
different outcomes – in this case the defaults - APPROVE or REJECT. Users will be able to choose one of
these outcomes to complete the task. (Note that you can configure additional outcomes if needed by
clicking the icon to the right of Outcomes.)

To determine what outcome the user selected, let’s define a data object to store the outcome as text. In
Browse Data Objects, right click on the Data Objects under PermitProcess and select Add.

Call the data object SiteReviewOutcome with a type of String and click OK.

Drag the SiteReviewOutcome to your Human Task’s Outcome target as shown. Click OK.

On the Review Site Information Human Task Attributes, let’s override the title with Permit Review - Site
Information.

Check the Data Associations link.

View the Input and Output tabs. Notice that PermitApplication and SiteReviewOutcome data objects
have already been associated from the human task creation.

Click OK and OK again to complete Review Site Information human task implementation.

Next, let’s reuse the previous human task definition for the Review Plans task. Double- click the Review
Plans task and click on the Implementation tab. Click the icon to the right of where it says Human Task.

Select the PermitReviewTask. This is the same task we created earlier.

On the Review Site Information Human Task Attributes, override the title with Permit Review – Plans.

Click the Data Associations link. Since we are re-using an existing definition, we have to manually do the
data associations. Previously, this was done automatically.

In the Input tab, map the PermitApplication under PermitProcess from the right with the
permitApplication on the left.

Go to the Output tab. Similar to the SiteReviewOutcome, let’s define another data object to store the
outcome of the Review Plans task. Right click on the Data Objects folder on the right and select Add.

Call the data object PlanReviewOutcome with a type of String and click OK.

Drag the outcome Output text argument on the left to the PlanReviewOutcome data object on the right.
Click Ok.

Click OK and OK again to complete the Review Plan human task implementation.

IMPLEMENTING THE SIMPLE USER TASK FOR PERMIT REVIEWS

For the last task, Review Construction Codes, we will need to implement a complex pattern because the permit
will have to be dynamically assigned to the appropriate official depending on the type of permit. For this
workshop, we will route to 2 officials – the Plumbing Official for plumbing related permits and the Electrical
Official for electrical related permits.

2. Right-click the Review Construction Codes task and select Properties. Click on the
Implementation tab. Click the icon to the right of where it says Human Task.

3. Name the task ConstructionCodeReviewTask and select the Complex pattern. Give it a
Title of Construction Code Review.

Click the icon to the right of where it says Parameters to assign a data object.

In Browse Data Objects, you should see the PermitApplication you defined earlier. Drag the
PermitApplication to your Human Task’s parameter table. This will make the Permit Application
accessible from the Review Construction Codes task.

As shown above, the Construction Code Review can return an outcome of APPROVE or REJECT. To
determine what outcome the user selected, let’s define a data object to store the outcome as text. In
Browse Data Objects, right click on the Data Object under PermitProcess and select Add.

Call the data object ConstructionCodeReviewOutcome with a type of String and click OK.

Drag the ConstructionCodeReviewOutcome to your Human Task’s Outcome target as shown. Click OK.

On the Review Construction Codes Human Task properties, change the Title to be of Simple
Exp. and enter the text (including the double quotes):

"Construction Code Review for Permit " + PermitApplication.system.referenceNumber

Optionally, you can click the icon to utilize the Expression Editor to construct this.

Click OK.

Because this task uses a Complex pattern, we will need to do the necessary assignments from the
human workflow task definition editor. In the process diagram, right click on the Review Construction
Codes and select Open Human Task.

The task definition editor will open. Click the Assignments tab from the right and double- click where it
says Edit Participant.

On the Add Participant Type dialog, specify a label of Electrical Official.

On the Participant List, Click on the Green +icon and add a group with a value of ElectricalOfficial

Note: This is a group defined in your server’s LDAP provider. This has already been pre- configured in the
server. You can also click the icon to browse the available groups and users from the LDAP server
as shown:

Expand the Advanced settings and check the option to Specify Skip Rule.

For the skip rule, click the icon to launch the Expression Builder and graphically construct the expression
as shown below:

Optionally, copy and paste the text below for the skip rule:

/task:task/task:payload/ns0:PermitApplication/ns0:Summary/ns0:RequireElectricalPermit="false"

Note: This specifies that this task will be skipped for any application which does not require electrical
permits. The expression is formulated from the task’s data structure which uses the Permit Application
schema as its payload. Optionally, you can also use the graphical Expression Builder by Click OK to add
the Electrical Official as a participant. You should now see the Electrical Official in the task definition
editor.

4. Click on the Electrical Official participant in the middle, then from the task definition’s toolbar, click the
icon and choose to add a Parallel participant block.

Do the same steps as above to add the PlumbingOfficial group as a participant.

Check the option to Specify Skip Rule and copy and paste the following condition:

/task:task/task:payload/ns0:PermitApplication/ns0:Summary/ns0:RequirePlumbingPermit = "false"

Or optionally construct it using the Expression Editor.

5. You should now see the 2 officials in the assignment configuration as follows.

6. Now let’s configure the overall outcome. Double-click the icon in the middle of the Electrical
and Plumbing Officials.

In the Vote Outcome, change the Voted Outcomes to REJECT and select immediately trigger voted
outcome when minimum percentage is met. This means that if either official rejects, the outcome will
immediately be REJECT.

Check the option to Share attachments and comments.

Click OK.

Let’s add a step to notify the Process Owner of the permit approval results.

Click the Stage 1 box which contains the Electrical Official and Plumbing Official, then from the task
definition’s toolbar, click the icon and choose to add a Sequential Stage.

On the new Stage 2, double-click where it says Edit Participant.

Change the Type to FYI and specify the label as Notify Process Owner. On the Participant List, add a
Group with the Name Value of PermitProcessOwners as shown. (Note: Similar to earlier, you can also
click the icon to browse for the PermitProcessOwners from the LDAP server.)

Click OK. Your task assignment should now look like this:

Click the Save All icon and close the task definition editor.

You now have all your human tasks implemented. There should be no more warning signs on the green
boxes as shown below:

LESSON 1 – SERVICE TASK IMPLEMENTATION
Let’s implement the Service Tasks for each automated activity. Automated activities are the ones with the blue
boxes.

IMPLEMENTING ZONING INFORMATION SYSTEM AS A WEB SERVICE

Implement the first automated activity, Get Zoning Information using a Web Service.to achieve continuous
process improvement.

1. Import the Zoning Information Web Service to the BPM Business Catalog. From the BPM Project
Navigator, expand the PermitProject > Business Catalog folder.

Right-Click on Services and choose New > Web Service. (Notice all the Adapters Services that you can
utilize for various types of connectivity.)

Name the Web Service ZoningInformationService and make sure to set the type as Reference.
References are services that the process consumes.

Click the icon on the right of WSDL URL to locate the service (Note: If you can also type the WSDL URL
directly).

From the SOA Resource Browser, select Resource Palette from the top instead of File System. Expand
the IDE Connections > Application Server to locate the ZoningInformationService as shown:

Note: the ZoningInformationService is already registered in the SOA Infrastructure. If it’s running
elsewhere, you can enter a WSDL URL, choose a WSDL file pointing to the web service, or select it from
a UDDI Server.

Notice the WSDL URL was filled in based on the service you located. Click Ok.

Note: If the Loading of the WSDL popup takes a long time (more than 5 seconds), click cancel and
continue.

From the BPM Process, double-click the first automated activity, Get Zoning Information and click the
Implementation tab. Leave the Implementation Type as Service Task. On the right of the Conversation
field, click the icon,

We will need to define a new conversation for this service. Click the icon on the Conversation
window to create a new conversation.

Name the conversation ZoningInformationService and choose Service Call as the Type.

Click the button beside Service and select ZoningInformationService. Click OK until you reach the
property window.

Select the Operation executes and then click the Data Associations link.

In the Data Association Input tab, expand the zoningInformationRequest on the right and map the
information from the PermitApplication process object as follows:

PermitApplication.summary.block ⇒ zoningInformationRequest.block
PermitApplication.summary.lot ⇒ ZoningInformationRequest.lot
PermitApplication.summary.siteAddress ⇒ ZoningInformationRequest.siteAddress

Click the Output tab, expand the ZoningInformationResponse on the left and map the information from
the PermitApplication process object as follows:

zoningInformationResponse.zone ⇒ PermitApplication.system.zone

Click OK on each dialog box until you’re back in the BPM process

Click the Save All icon.

IMPLEMENTING THE PAYMENT PROCESSOR AS A DATABASE ADAPTER SERVICE

Implement the last automated activity, Process Payment. Typically, the process payment activity will be handled
by another process that will orchestrate the calls to an external credit card validation service and potentially
internal billing and order management systems. For the purposes of this workshop, we will just invoke a
database operation to store the payment information in a database table.

1. Now, let’s utilize the Database Adapter to import the Permit Payment tables from the Oracle database
into to the BPM Business Catalog. From the BPM Project Navigator, expand the PermitProject > Business
Catalog folder.

Right-Click on Services and choose New > Database Adapter.

This will launch the Adapter Configuration Wizard for the Database Adapter. Click Next.

On Step 2 of the wizard, name the Database Adapter Service PaymentProcessingService. Click Next.

On Step 3 of the wizard, click the icon to create a new Database connection and enter the following
info:

• Connection Name: PermitAppDB
• Username: PERMIT_APP
• Password: welcome1
• Host Name: localhost
• SID DB11G

Click on Test Connection and you should see a “Success!” message. If not, make sure you entered the
correction information from above. Click Ok.

Back on Step 3 of the wizard, verify that the JNDI name uses the connection name:
eis/DB/PermitAppDB. Click Next.

(Note: This JNDI name is the link to the database adapter connection configured in the server.)

On Step 4, select the radio button Perform an Operation on a Table. Make sure only the check box for
Insert only is selected. Click Next.

Click Import Tables.

Click Import Tables. Click Query. You should see 2 tables, PAYMENT and PERMIT_APPLICATION, on the
left. Click the icon to shuttle the 2 tables to the right. Click OK.

You may have to wait a few seconds. When the Step 5 window appears. Select PERMIT_APPLICATION as
the root table and click Next.

Click Next on remaining steps to confirm the Relationships that were automatically captured between
the 2 tables.

Click Next on the remaining steps to accept the default values and click on Finish.

2. You should now see the PaymentProcessingService in your catalog.

From the BPM Process, double-click the last automated activity, Process Payment and click the
Implementation tab. Leave the Implementation Type as Service Task. On the right of the Conversation
field, click the icon

We will need to define a new conversation for this service. Click the icon on the Conversation
window to create a new conversation.

Name the conversation PaymentProcessingService and choose Service Call as the Type.

Click the icon and then select PaymentProcessingService. Click OK till you come back to the
Properties screen of Process Payment.

From Operation drop down, select insert and the click Data Associations.

Click button and drag it on the permitApplicationCollection. This will allow you to define a data
transformation.

On the Source select PermitApplication business object and clickbutton to select it as Source. Keep
the default target. Keep the Create option selected as Transformation and then click OK.

Click OK on the open dialogs until the Data Association window is closed.

You should see the PermitApplication_PermitApplication.xsl transformation editor.

Expand the PermitApplication element on the right and expand the Payment element underneath it as
shown. This shows the table structures of the PERMIT and PAYMENT tables captured by the database
adapter.

Now we will make use of Automatic Mapping to map the source elements to the target elements. Drag
tns:PermitApplication from the left to PermitApplicationCollection on the right as shown:

You will be prompted for Auto Map Preferences. Make sure the Auto Map Preferences are the same as
below and click OK to have the fields with similar names automatically mapped

You should see all the fields in the target automatically mapped except for payment_id. We do not have
to map the payment_id since this will be automatically incremented in the database by a database
sequence.

Right-click on tns:PermitApplication from the left and select Expand All. You should see the individual
elements from the source mapped to the target.

Close the Transformation Editor by clicking the x button on the tab.

You now have all your service tasks implemented. There should be no more warning signs on the blue
boxes as shown below:

LESSON 8 – BUSINESS LOGIC IMPLEMENTATION
Now implement the permitting logic by defining the business rule, conditional flows and script tasks.

IMPLEMENTING BUSINESS RULES

We will now implement the Business Rule for determining whether permit applications require preliminary
reviews or not. The business rule is the one with the yellow box.

1. From the BPM Process, double-click Evaluate Permit business rule and click the Implementation tab.

Click the icon on the right of Business Rule to create a new business rule definition and name it
PermitApplicationRules

On the right of Input and Output Data Objects, click the icon and select Add Input Data Object.

From the Browse Data Objects window that appears, drag PermitApplication to the left section to add it
as a business rule input.

Click the icon again and this time, select Add Output Data Object.

From the Browse Data Objects window that appears, drag PermitApplication again to the left section
this time to add it as a business rule output.

Click OK to create the business rule dictionary. (Note: This may take a minute.)

Check the Data Associations link and make sure PermitApplication is assigned to both the input and
output fields.

2. Let’s initialize some of the system data we need to generate like the status and reference number
before evaluating the permit application. From the Input, expand the PermitApplication and system.
Then drag the expression icon to the target node ApplicationStatus.

In the expression builder window, enter the value “Submitted”.

To assign a unique reference number, we will make use of a predefined XML Path function to get the
process instance identifier. Drag the icon on the referenceNumber to bring up the Expression
Builder editor.

In the Expression Editor, change the mode to XPath Exp. and enter the expression
ora:getCompositeInstanceId(). This will give you the unique process instance identifier assigned by the
BPM engine.

Note: You can also select getCompositeInstanceId from the list of available functions shown on the
bottom right of the expression editor or under Predefined Variables (compositeInstanceId). The XPath
mode provides more advanced capabilities in formulating your expressions using a wide set of XML Path
functions.

You should now have something like this

Click OK and Ok again to go back to the BPM Process.

We will now implement the rule as a Decision Table. From the BPM Process, right click the Evaluate
Permit business rule activity and select Open Business Rule.

This will bring you to the Rules Editor. From there, click on Create Decision Table.

Let’s create a condition for the Project Size based on the Permit Application’s Estimated Cost. Click on
<insert condition>.

Double-click on <edit condition> and drill down the value options for
PermitApplication.summary.estimatedCost.

We’ll need to define a bucket set to classify the permit applications based on project size.
We want to classify projects as large, medium or small. The bucket set will define what is considered
large, medium and small based on the permit application’s estimated costs. For this example, let us
consider the following:
• Projects greater than or equal $100,000 are large projects.
• Projects greater than or equal $10,000 and less than $100,000 are medium projects.
• Projects less than $10,000 are small projects.

Under DecisionTable1, make sure the Local List of Ranges is selected and click the icon on the right of it
to define the bucket set ranges.

In the Edit Bucketset window, enter the name Project Size and Data Type of int. Click the green plus sign
to add two buckets. Edit the values as follows:

Endpoint: 100000 Alias: Large Description: Large Projects
Endpoint: 10000 Alias: Medium Description: Medium Projects
Endpoint: -Infinity Alias: Small Description: Small Projects

Click Ok.

Back in the Decision Table, select the empty cell ( ?) under R1 and choose the Small checkbox. Click
outside of the cell to complete the assignment.

Use the green plus sign to add a second Rule. Set this one to Medium. Add a third Rule and set this to
Large. These three rules, which are the ranges defined earlier, are evaluated against the value of
PermitApplication->summary->estimatedCost.

Now set the Actions for these three rules. Left click the <insert action> link and select Modify.

Right click on the text that says “modify…” action and select Edit.

From the Action Editor dialog, select the Target as PermitApplication.system and choose
ApplicationEvaluationResults as the argument. Then, select the checkbox for Parameterized and also
select the checkbox for Always Selected. Click OK.

Now we’ll set the return values. In the Actions pane, select the cell for each of the three rules and set
the return value for each one:

Small Projects (R1) = NO_REVIEWS_REQUIRED
Medium Projects (R2) = REVIEWS_REQUIRED
Large Projects (R3) = REVIEWS_REQUIRED

The finished Decision Table looks like this:


Close the Rules Editor by clicking the x button on the tab

IMPLEMENTING THE CONDITIONS
Now implement the conditional logic of the process. We will add the expressions for each conditional transition.

1. Double-click the transition that returns from the Preliminary Review Outcome gateway going back to
Apply for Permit. This condition occurs when either the Zoning Office rejects the site information or the
planning office rejects the plans.

Click on the Properties tab and enter the following condition:

Tip: You can click on the Expression Editor icon to graphically construct the expression. Optionally, copy
and paste the following text for the condition:

PlanReviewOutcome = "REJECT" or SiteReviewOutcome = "REJECT"

Click Ok.
2. Next, double-click the transition that bypasses the preliminary reviews to go straight to the Review
Construction Codes. This condition occurs when EvaluatePermit business rule returns a value of
NoReviewRequired.


Tip: You can press CTRL SPACE while editing to display a dropdown of valid values. Optionally, copy and
paste the following text for the condition:

PermitApplication.system.applicationEvaluationResults = NoReviewsRequired

Click Ok. (Note: Don’t just hit Enter. Make sure to click OK to preserve your edits).

3. Lastly, double-click the transition that returns from the Review Outcome gateway going back to Apply
for Permit. This condition occurs when the Construction Officials reject the construction codes.


Optionally, copy and paste the following text for the condition:

ConstructionCodeReviewOutcome = "REJECT"


IMPLEMENTING THE SCRIPT FOR TASK INITIALISATION
Use of a Script task to initialize our permit application. The Script task is useful for initiating or setting any
constant values in the data objects. For the purposes of this workshop, we will initialize the permit application
with default data to save us from having to type all the information manually when we run this.

1. Select all the objects in the process except Start and move them a bit to the right to make some room
between Start and Apply for Permit.

Note: You can drag a box over all the objects you want to select or just multi-select the individual
objects.

From the Component Palette under Activities, drag a Script task to the process and drop it between the
Start and Apply for Permit.

Name the task Initialize Permit Application.

Double-click Initialize Permit Application script task and click the Implementation tab.

Check the Data Associations link.

From the Data Associations, drag the XML Literal on PermitApplication.

The XML Literal Expression Builder should come up.

Navigate to the directory /home/oracle/MyFiles/Implementation and double-click the file called
SamplePermitApp.xml to open it in the default Text Editor. Copy the contents of the
SamplePermitApp.xml (Edit - Select All and Edit -Copy).

BPM Process should now look like this:

To validate that there are no problems, click the Make icon in JDeveloper.

You should get the following output in the SOA log window

LESSON 9 – BUSINESS ACTIVITY MONITORING
IMPLEMENTATION
ENABLING BUSINESS ACTIVITY MONITORING DATA COLLECTION

Now enable Business Activity Monitoring and make use of Business Indicators in our Permit
Process for more real time process monitoring capabilities

1. From the BPM Project Navigator, right-click on your PermitProject and select Project Preferences.

Change the Project Sampling Point to Generate for All activities. This will allow us to monitor both
human and automated activities in the BAM dashboard.

On the Business Indicators tab under Process Analytics Summary, add the following business indicators
by clicking the icon and selecting the Business Indicator type:

Business Indicator type Name Type
Counter PermitApplicationCount Int
Counter PermitApprovalCount Int
Dimension Zone String
Dimension TypeOfWork String
Measure Cost Real

2. You should have the following:

Click the Data Targets tab and check Enable BAM. For the BAM Adapter JNDI name, select
eis/bam/soap. (Note: This has already been pre-configured. Please refer to Appendix D for configuration
instructions).

Click OK.

ENABLING BUSINESS ACTIVITY MONITORING DATA COLLECTION
Now let’s add counter marks and assign values for the business indicators in the BPM process. We will mark the
permit application and set the indicators after the business rule execution.

1. Open the PermitProcess, and double-click on Evaluate Permit rule. Click on the Implementation tab and
click Data Associations link.

In the Data Associations editor, inside Output tab, open the PermitProject node and you will be
presented with some fields as shown below. These fields need to be mapped. Expand PermitProject >
DataObject. You should see your newly created business indicators.

2. Drag the estimatedCost and TypeOfWork from permitApplicationOut.summary on the left to the Cost
and TypeOfWork business indicators on the right. Drag zone from permitApplicationOut.system on the
left to the Zone business indicator on the right,

Click OK and OK again to go back to the process.

Back in the process, right–click on the Evaluate Permit rule and select Add Counter Mark.

Check the PermitApplicationCount in the Add Counter Mark dialog box and click OK.

At the end of process, right–click on the Process Payment activity and select Add Counter Mark.

Check the PermitApprovalCount in the Add Counter Mark dialog box and click OK.

Click Save All icon and close the process.
To validate that there are no problems, click the Make icon in JDeveloper

Note: The Compiler Output will show warnings about the Error assignee not specified. You can ignore
these warnings.

LESSON 10 – USER INTERFACE FORMS GENERATION &
CUSTOMISATION
Before we can deploy and execute, you’ll need a way for users to interact with the human task in the Permit
Process. The integrated development environment of Oracle BPM Suite includes Oracle Application
Development Framework (Oracle ADF) for this purpose. With Oracle ADF, you can design a task form that
depicts the human task in the BPM Process. You can also automatically generate the forms based on the input
and output parameters defined for the task form. In this lab, we will generate task forms for the each of the
human tasks in the process:

 Apply for Permit
 Review Site Information
 Review Plans
 Review Construction Codes

GENERATING/CUSTOMIZATION THE PERMIT APPLICATION FORM

1. In the PermitProcess, right-click on the first activity, Apply for Permit and select Create Form > Auto-
Generate Task Form.

This will ask you to create a new project. Enter the name PermitApplicationForm.

Click OK when prompted to accept the default Table Columns. This will generate a new ADF Task Form
Project. (Note: This may take a minute to generate). You should see the task form below.

Change the following fields to a check box:
 Require Building Permit
 Require Plumbing Permit
 Require Electrical Permit
 Require Fire Permit

Right-click on each field and select Convert To.

Choose Select Boolean Checkbox and click OK twice to confirm the Attribute Binding and the
conversion.

Clear the Text property for each check box by clicking the checkbox field and changing the Text property
in the Property Inspector under Appearance > Label and Text

Your check boxes should look like this:

Click the Proposed Design field and from the Property Editor on the right, change the Columns to 50 and
the Rows to 5.

Click the box surrounding Permit Application – System, until you see the border highlighted. Delete it by
right-clicking the border and selecting Delete or by pressing the Delete key in your key board. The values
of these fields will be generated by the BPM Process and we do not need this for the initial data entry.

Click the CreateInsert button and from the Property Editor on the right, change the Text to Add.

Lastly, make the Type of Work field to a select list box with a short list of values to choose from. Right
click Type of Work and select Insert after Input Text … > Select One Listbox. Get the option from left
bottom Structure view as shown below.

On step 1, select the option to Create list and enter the following as Item Labels and Item Values:
 New construction
 Structural
 Mechanical
 Demolition

Click Next. On Step 2, enter Type of Work as the label, 4 as the size and
#{bindings.TypeOfWork.inputValue} for the value.

Click Finish.
Select the original Type of Work Field and delete it by Delete key in keyboard.
Click Save All .
Your form should now look like this:

Right click on the PermitProcess tab and choose Close Others, to close everything except your BPM
process.

GENERATING/CUSTOMIZATION THE PERMIT REVIEW FORM

1. Back in the PermitProcess, right-click on the Review Site Information and select Create Form > Auto-
Generate Task Form.

Name it PermitReviewForm

Click OK when prompted to accept the default Table Columns. Again, this will generate a new ADF Task
Form Project. (Note: This may take a minute to generate).


Since the process will only use this form for reviews, it will be accessed for read-only. We do not have to
modify the fields unlike the data entry form.

Your form should now look like this

Click Save All and close everything except the BPM Process.

Note that you do not have to generate a separate form for the Review Plans activity because it is using
the same task definition as the Review Site Information activity. It will just use the same
PermitReviewForm you already created.

GENERATING/CUSTOMIZATION THE PERMIT CONSTRUCTION APPLICATION FORM

1. Back in the PermitProcess, right-click on the Review Construction Codes and select Create Form > Auto-
Generate Task Form.

Name the form PermitConstructionOfficialForm and click Ok.

Again, you should see a new form generated. (Note: This may take a minute to generate).

Your form should now look like this:

Click Save All and close everything except the BPM Process.

Click on the Application Navigator, you should now see 3 additional projects: Permit ApplicationForm,
PermitReviewForm and PermitConstructionOfficialForm, together with your PermitProject.

Congratulations! You have completed filling in the implementation details for the Permit Process
without any coding. Using declarative tools, you have defined human workflow task configurations,
web service calls, database adapter services, data associations and transformations, business rules ,
conditional logic, script tasks and even generated user interface forms using the Oracle Application
Development Framework.

LESSON 10 – PROCESS DEPLOYMENT
Lastly, we will map the process roles to the actual roles that these users are assigned to in a Corporate
Directory/LDAP Server and then deploy the process to the BPM/SOA runtime environment running on Oracle
WebLogic Suite.

ASSIGNING PROCESS PARTICIPANTS

2. BPM is about tying in People, Process and Technology. We’ve create the Process, configured the
Technology, now let’s now get our People to participate with the process The following users will be
participating in the Permitting Process with the respective roles and responsibilities:

We will need to map the Process Roles to the actual roles that these users are assigned to in the
Corporate Directory/LDAP Server. For this workshop, we will use the embedded LDAP server in the
WebLogic Application Server. All these users and their corresponding groups have already been defined
in the LDAP Server.

3. From the BPM Project Navigator, expand the PermitProject folder and double click Organization. You
should see the Organization Editor in Oracle BPM Studio showing the process roles.

Click on the Applicant role and switch the Type to Group.
Click the sign to add a member to the Applicant role.

Enter Citizens for the Name.

Do the same for the other Applicant Roles using the LDAP Server Groups as follows:

Process Role LDAP Server Group
Applicant Citizens
Construction Officials PlumbingOfficials
ElectricalOfficials
Planning Officer PlanningOfficers
Process Owner PermitProcessOwners
Zoning Officer ZoningOfficers

4. Note: Make sure that the LDAP Server Group name you type is exactly the same as the name in the
WebLogic LDAP Group list in the previous page.
Note: Optionally, you can use icon to browse the available groups and users from the LDAP server as
shown:

Click Save All and close everything including BPM Process.

DEPLOYING THE PROCESS
1. Go to 'Application Properties' -> Deployment -> Uncheck the 'Auto Generate and Synchronize weblogic-
jdbc.xml Descriptors During Deployment' option and click OK.

2. Go to the Application Navigator and right-click the PermitProject. Select Deploy > PermitProject.

3. Choose Deploy to Application Server and click Next.

Click Next to accept the default Revision ID.

Make sure you check the boxes to select the 3 task form projects. This will include these projects in the
deployment. Click Next.

Select the Application server SCAServer and click Next.

Note: This has already been configured to point to the local WebLogic Server. Please refer to Appendix
C for instructions on how to configure this.

Click Next to accept the default partition.

Click Finish to proceed with the deployment

This may take a few minutes since each task form all has to be uploaded and deployed. Monitor the
Deployment log and wait for the following message:

You have successfully deployed your Permit Process to the server.
You can re-execute the process by following the steps in Lab 4 – Process Interaction.

Oracle BPM 11g Lesson 2

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Oracle BPM 11g Lesson 2 (20)

Oracle BPM 11g Lesson 2