Scenario Introduction for Redbooks Wiki
In order to provide a realistic context which demonstrates how the BPA Framework can add value and provide integration between WebSphere Process Server, WebSphere Portal Server, and Lotus Forms, we have created a scenario based on a Purchase Ordering System. We are basing this on a fictitious company called APIS Retail.
The primary objective of this redwiki exercise was to utilize the BPA framework to address a moderately complex business problem. The scope was consciously chosen to be limited enough to allow a small team to complete the work in a few weeks’ time but broad enough to cover typical real-world requirements. The use case selected was that of a Purchase Order with three major tasks:
initial order entry by a Customer,
order review and approval or return for re-work by a Reviewer, and
fulfillment by a Supplier.
The major characteristics of this Purchase Order process included the following:
Conditional logic: Differentiated flows depending on the order size – under $75 follows an expedited path; $75 or over requires additional oversight.
Iteration: Option for returning orders to purchasers for additional input (missing or inaccurate information)
Order entry assistance: Accelerating and simplifying the ordering process by providing Purchasers with information about previous orders, and leveraging WebSphere Portal and BPA framework functionality to present information about previously ordered items (and order history) to automatically pre-populate selected data into a new order from retrieved information.
Differentiated behavior for use case actors with different roles and belonging to different organizations: The BPA solution provides the ability to assign Potential Owners (people assignment) for any task in a business process. In the case of our specific Purchase Order scenario we had three roles:
(1) a Purchaser / Customer,
(2) a Reviewer, and
(3) a Supplier who fulfills the order.
The following table outlines the key behaviors and underlying technical highlights within the use case, based on each of the different roles.
Based on sign on to Portal Server.
Purchase Order wizard driven Form simplifying the order entry process
- A few (4) wizard pages including a signature page providing complete data capture. This allows follow-on tasks to view this data in summary formats.
- Pre-populate data instance(s) based on information passed between portlets on Purchase Orders page (triggered by selectable links in other portlets)
- Dynamic Tables (Arrays of data) allowing adding items to order
- Pre-populated “vendor” specific information
- Simple Click Wrap sign off for a section of form – contact information
- Business Object (BO) encapsulates data coming from process step, passed into the Form
- Notification when PO is approved or requires additional information.
- Business process rules based on PO amount, less than a certain amount = auto approve, over a certain amount = additional approval required.
- Extension Point: Web Service call for Vendor Data look-up to Vendor Database (can be shown in another portlet, and wired to form via vendor number)
- Extension Point 2: Product Data lookup based on Vendor, and previous purchases.
- Attachments stored in File System.
- Form can be stored in File System once submitted.
- Returned forms include comments from BO depending on process state.
- Notification sent to inbox in portal
Corporate Review and Approval
- A new page on the PO Form showing only data appropriate to this task
- Carries forward data from BO from initial Customer submission of Purchase Order
- Highlighted information
- Prioritization based on in-Form, or Process Logic.
- Simple Click Wrap on decision to approve/deny with comments
- Pre-populate instance data in the form from BO or web service for options
- Simple Click Wrap sign off for a section of form – on comments.
- Notification sent to inbox in portal when initial form submitted.
- Process State dictates what is exposed in form.
- BO persisted through out process and to both forms as needed.
- Upon completion Form stored in File System.
Receives order, checks stock, verifies credit, ships product
- Supplier logs in, different themes and skins on portal
- Notification of new PO, Opens Form (new form generated from data contained in the BO).
- Look up stock to generate Packing Slip (Form #3)
- Out of stock items are marked with expected ship dates
- Packing Slip sent to Warehouse to complete Order
- Notification of new order received
- Extension point, check stock – Out of stock marked on packing slip
- Extension point 2: Credit check based on Purchaser ID
* Note: Extension points for the Supplier role are not implemented in this example.
Overview of the Process Flow
The scenario selected by the team is a generic Purchase Order process. There are four main process states, and three forms associated with the process. Each of the forms contains an XForms Data model not only for the data on the form itself, but also the data instance for the business process. The process state determines which form is used to render the data. The four process states are described in detail below.
Process Steps From an End User Perspective
Step 1 Initiate Order
When a “Customer” logs into portal, the login information is captured and passed to the “Form List Portlet”, part of the BPA framework, which shows a list of forms used to initiate new processes. First, let’s look at the Purchase Orders page presented by WebSphere Portal:
Note that this Forms List portlet is “wired” to react to a selection of a form by opening that form in the Form View portlet on a different page (New Purchase Order) as follows:
A new process is initiated by selecting the “Purchase Order” from the “Form List Portlet” to open a new purchase order, the first form in the process. Again, the login information is passed to the form upon open, and if the customer exists in the database, the customer data such as contact name and address are pre-populated on the form. If this is a new customer, a new record will be created in the customer table after the form is submitted.
When the user opens a new purchase order form, a second portlet is displayed showing previous submitted purchase orders from the logged in customer. The second portlet uses webservice calls with the login information to display data contained in the customer table of the database to assist the Purchaser in filling out the order.
Selecting an order from the list of historical orders will cause the third portlet to load with detailed line items for that order, and selecting a specific line item will send item information to the Form View portlet on the left, resulting in a refresh and automatic population of item data into the current order. All this behavior is accomplished with a combination of WebSphere Portal wiring functionality and BPA framework functionality which facilitates the data handling aspect of the solution (see screenshot below):
For repeating orders, existing customer may easily copy data from the Order Details portlet by double clicking on one of the line items. This portlet-to-portlet communication uses the property broker in the BPA framework.
The purchase order form uses webservices for data look-up for information such as price, discount and tax. This makes it easy for even new customers to fill out purchase orders. Simply select an item from the pull down list, put in the quantity required, and the rest of the table is calculated automatically. When the user submits the form, the process is initiated with the new process data, the form data is stored in the orders table, and the completed form is stored in the file repository.
Step 2 Review Order
After initiation, the next step in the process is a conditional check on the total amount stored in the process data. If the amount is less than $75, the order is automatically approved and sent to the supplier, skipping the “Review Order” step. Otherwise, the order shows as a new task in the “Approver’s” task list as a Purchase Order requiring approval.
The “Approver” may “claim” the form needing approval by checking the form and selecting the task using the check box, and pressing the “Claim” button, or by dragging-and-dropping the form on the Web 2.0 hot-spot shown to the right of the task list.
After claiming the task, the Approver clicks on “Review Order” to open the Purchase Order. This order opens on a new page which shows a summary of the order data, and has a section for comments for the Approver.
If the Approver determines the order requires additional information, it gets routed back to the Customer with comments, and will continue to loop through this process until it is “Approved”. Once approved, the form will be sent to the supplier.
Step 3 Update Purchase Order
If the “Approver” requires additional information, it is sent back to the “Customer” with comments. The customer receives a new task showing a “Purchase Order Requiring Update”
When the task is opened, the data is displayed in the original form, with the Approver comments added. Upon submit of the updated Form, the process data is maintained, and the original form data is replaced with the new form data. Due to very limited time, the team chose to replace the form data instead of building the logic to determine what data had changed. This would not be the preferred method in production as it does not maintain an audit trail of the form data.
When the form is submitted, it goes back to the Approver, and continues to loop through this process until it is approved.
Step 4 Supplier Checks Stock and Generates Packing Slip
The final step in the process is for the supplier to generate a packing slip. The supplier receives notification of a new order in the task list. When the order is opened, the data is rendered on a third form which displays the order data, and has a button to generate the packing slip with shipping information.
The packing slip is shown below.
Once the packing slip is generated, the supplier hits “Submit Approval” which terminates the process.