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 click button 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.

Click the Save All icon. 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:

Click the Save All icon. 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.

Click on the Properties tab and enter the following condition:

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.

Click on the Properties tab and enter the following condition:

Optionally, copy and paste the following text for the condition: ConstructionCodeReviewOutcome = "REJECT" Click the Save All icon.

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.

Click the Save All icon. 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).

Click the Save All icon. 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.