Working with Business Processes and Web Services

This chapter provides overviews of business processes and web services and discusses how to:

• Set up business process security.

• Set up CRM and Business Process Execution Language (BPEL) integration.

• Define business process states.

Understanding Business Processes

This section discusses:

• BPEL and the Oracle BPEL Process Manager.

• CRM integration with the business process monitor.

• Business process monitoring.

• Business process development: considerations.

• Business process initiation: considerations.

BPEL and the Oracle BPEL Process Manager

BPEL is an industry standard language for defining business processes for orchestrating activities that can spawn across disparate systems. These activities could be exposed as web services. The Oracle BPEL Process Manager enables enterprises to model, deploy, and manage business processes. It includes a BPEL modeler, a scalable BPEL engine, an extensible WSDL binding framework, a monitoring console, and a set of built-in integration services.

This diagram illustrates how the Oracle BPEL Process Manager orchestrates and manages business processes involving operations that occur in multiple disparate systems:

Developing and managing business processes in Oracle BPEL Process Manager

See Oracle BPEL Process Manager documentation

CRM Integration with the Oracle BPEL Process Manager

Oracle BPEL Process Manager includes different components that are used to create (BPEL Designer) and execute (BPEL Engine) business processes. Because Oracle BPEL Process Manager and PeopleSoft CRM typically run on separate environments, an infrastructure is being built to integrate these two systems, allowing CRM transactions to invoke and monitor business processes from the PeopleSoft side without physically going to the other system. This infrastructure enables you to:

• Initiate business processes from within CRM transactions.

• Create worklist entries from business process activities and provide user input through CRM worklists.

• Monitor business process instances and view activity status in the business process monitor.

Note. The design and construction business processes take place on the Oracle BPEL Designer only.

Initiating Business Processes

CRM transactions can initiate both asynchronous and synchronous business process instances in one of these two ways:

• Calling an application programming interface (API).

  • When an asynchronous process is initiated successfully, it returns a conversation ID to the CRM system and this unique ID can be used to identify the corresponding business process instance.

    The CRM system maps asynchronous business process instances with their initiating transactions, enabling users to access the status information of process instances from their transactions.

    If an asynchronous process instance expects an input, the execution is on hold at that point until the input is received.

  • When a synchronous process is initiated successfully, the process is executed in the BPEL Engine and the calling application is in a suspended state until a response is received from the BPEL Engine.

    After the execution completes, the engine returns a message (in most delivered business processes). CRM applications can use the information available in this message for further processing.

    In Call Center applications, a mapping between the name of the initiated business process and its initiating transaction is established so that users can view the status of synchronous process instances from the transaction.

    Note. The business process monitor does not support the viewing of synchronous process instances because conversation ID does not apply to them.

• Triggering an Active Analytics Framework (AAF) action.

  Transactions that support AAF can initiate business process instances using the Initiate Business Process action in their policies. This method is preferred for initiating asynchronous processes. You configure the action and provide the data (for example, the business process to initiate) that the action needs at runtime.

  Asynchronous business process instances that are initiated successfully using this method are associated with their initiating transactions and can be viewed on the business process monitor.

  See Understanding CRM Action Types.

If asynchronous business processes cannot be initiated due to issues on the server or network connectivity, you can resubmit the requests from the transaction directly.

Viewing Activity Status and Providing Input Data

The infrastructure provides the ability for business process activities to create manual worklist notifications in the CRM system. Users can provide outcome information as well as application-specific input that is expected by the associated activities. User response is returned to the corresponding activities to allow proper execution of the business process instances.

See Understanding Business Process Worklist Entries.

Monitoring Business Process Instances

The infrastructure includes a monitoring tool that provides status information for asynchronous business process instances. The tool displays business process instances in milestones and provides statuses both for the overall instance and at the milestone level, giving functional users a simple and effective snapshot of the current status. Users can access the monitor from initiating CRM transactions, the 360-Degree View, and My Worklist.

See Understanding the Business Process Monitor.

Business Process Initiation

This diagram illustrates the process flow on business process initiation:

Business process initiation

A transaction can initiate a business process by one of these methods: calling the LaunchBPEL method in the Initiate Business Process API, or using the AAF framework that triggers the Initiate Business Process action. When a business process is being initiated:

1. The service operation name and optionally application-specific payload, which are passed to the API (or the action configuration, if AAF is used), are submitted to the Integration Gateway and hence the BPEL Engine as a request.

2. If the request is submitted successfully:

   • (For asynchronous processes) The infrastructure associates the conversation ID of the business process instance with the initiating transaction and returns the conversation ID to the transaction.

     To associate a business process instance to a different transaction, pass the transaction type and the name of the record that has the transactions' key values to the API (or AAF as context variables). For example, if a business process is initiated from a case and the instance needs to be associated with an order, the transaction type and the key values of order should be passed accordingly.

   • (For synchronous processes) The infrastructure returns the message that is generated from the BPEL Engine to the initiating transaction. The message is stored in the form of a property and it associates the service operation name (conversation ID does not apply to synchronous processes) with the transaction for history tracking purposes.

   • (For process instances initiated by AAF) The infrastructure adds the conversation ID in the form of an array (for asynchronous processes) or message in the form of a property (for synchronous processes) to the generated context. Information in the context can be used to carry out any AAF post-processing if applicable.

   If the request cannot be submitted due to the occurrence of fatal errors, for example, the service operation points to an invalid node or the business process cannot be uniquely identified because it is registered multiple times using different nodes, the submission process stops. The infrastructure does not support the re-submission of business process instances as a result of fatal errors. Users need to re-initiate the business process.

3. From the initiating transaction, users can view a list of initiated asynchronous process instances that pertain to it.

   They can access the status information of the instances using the business process monitor.

   For process instances that did not initiate successfully due to network or system outages, the infrastructure provides users the ability to resubmit the instances from the transaction directly.

   Note. Users can view a list of initiated process instances, both asynchronous and synchronous, for any given case on the Case component. In this scenario, synchronous process instances are not displayed in the business process monitor, which does not support synchronous process instances.

Business Process Monitoring

After business processes are initiated successfully, users can access their statuses from:

• Transactions from where business process instances were initiated.

• The 360-Degree View of customers who are associated with the initiating transactions.

• My Worklist of users who are associated with the initiating transactions.

Users drill into process instances to view status information from the business process monitor on the CRM system. The monitor retrieves status information of process instances from the BPEL server and provides a functional, milestone-based presentation of the information to business users.

Statuses are represented numerically on the BPEL server. In order for the business process monitor to display business process and activity statuses in a user-friendly manner, the CRM system provides mapping between the codes and the corresponding status description, which is used by the monitor.

The Oracle BPEL Process Manager includes a monitoring tool that is intended for technical users.

See Also

Defining Business Process States

Business Process Development: Considerations

Here are some recommendations for developing business processes to work efficiently in the CRM system:

• Each business process (asynchronous) should get a conversation ID at the very beginning of the process.

  The conversation ID is used whenever the process interacts with the CRM system, for example, for creating worklist entries or signaling the completion of the business process.

• The business process should call the HouseKeeping business process at the beginning and at the end (including any exception path) of the business process.

  It sends a message to the CRM system upon the instantiation and the completion of the business process.

• After the business process is developed and successfully deployed on a BPEL domain, it needs to be registered to the CRM system as service operations.

  PeopleTools provides the ability to create service operations by consuming the deployed web services description language (WSDL). The common way to locate the WSDL for consumption is to use the WSDL URL. The URL is available from the BPEL Console.

• For business process instances to display properly on the 360-Degree View page:

  • For process instances initiated by API, call the DoBOIDMapping method under RBB_INFRASTRUCTURE:InitiateBPEL to associate instances with the required BO_ID.

  • For process instances initiated by AAF, include the PopulateBOIDs method in the post-processing class to associate process instances to the proper BO_ID.

Passing Application-Specific Data Using AAF

If AAF is being used to initiate business processes and there is application-specific data that the infrastructure needs to have, that data should be passed as context variables. Available context variables are:

• BPEL_PURPOSE: Stores the purpose of the business process in the form of a string, which is used for display by the business process monitor in the Process Summary section.

  You can set the value by specifying the message set number and message number like so: 17834;9999;Check Credit History, in this case the translated purpose shows on the monitor. You can define the purpose while configuring the Initiate Business Process action. If this variable is defined, it overwrites the purpose that exists in the action configuration; if it is not defined, the purpose does not show on the monitor.

• BPEL_TXN_TYPE: Stores the transaction type of a transaction in the form of a string.

  Define this variable if you want to associate business process instances with a different transaction other than their initiating transactions.

• BPEL_TXN_RECORD: Stores the record object that has the transaction keys for the transaction type defined in the BPEL_TXN_TYPE variable.

The use of context variables is optional.

Payload is set in the configuration of the Initiate Business Process action.

Passing Application-Specific Data Using API

Similarly, you can pass the same kind of information to the infrastructure if you are calling the LaunchBPEL method to initiate business processes. Available properties are:

• Purpose (String): Set this value with a message set number and message number delimited by a semi-colon (for example, 17834;9999;Check Credit History) to have the value translated and displayed on the business process monitor.

  Otherwise, the string appears with out any translation (for example, Check Credit History).

• TransactionType (String): Set this value if you want to associate business process instance to a different transaction other than the initiating transaction.

  Note that the value should be in uppercase, for example, &oInitBPEL.TransactionType = "ORDER";

  where order is the other transaction with which business process instances associate.

  If this property is not set, the infrastructure uses the current component and market to derive the transaction type. If this property is not set for the business process and the current component does not have a transaction type, the business process cannot be initiated and an exception occurs.

• TransactionRec (Record): Set this value to the name of the record object that has key values of the transaction identified in the TransactionType property.

  Key values are derived from the component buffer using the Add record or Search record of the component if this property is not set.

Payload, if expected by the BPEL Engine, can be passed in the form of a message object (created using the Message Container) to the LaunchBPEL method.

Business Process Initiation: Considerations

To initiate a business process successfully, make sure to:

1. Deploy the business process on a BPEL domain successfully from the BPEL Designer.

2. Register the business process on the CRM system as service operations using the node that points to the BPEL Console.

3. Define transaction types for components that use business processes.

   See Setting Up CRM and BPEL Integration.

4. Specify business process and activity statuses.

   See Defining Business Process States.

5. Use the Initiate Business Process action in the AAF policy, if the business process is initiated using AAF.

   See Configuring Actions in Policies.

See Also

PeopleTools 8.52: PeopleSoft Integration Broker PeopleBook

Understanding Web Services

This section discusses:

• Web service basics.

• Delivered web services.

Web Service Basics

A web service is a standards-based web application that can be used to interact with other internet applications over a network. It is a standard way of exposing some operation or group of operations so external clients can make use of them. Common CRM transactions are exposed as web services through the service oriented architecture (SOA) so that an external system (such as the Oracle BPEL Process Manager) can perform various CRM actions without having to create system-specific integration points.

A web service can include one or multiple operations (actions that a web service can perform). For example, the CRM system delivers case as a web service and it contains a number of operations: create case, update case, get case, and search case.

Note. Oracle delivers web services for use with business processes. Some, but not all, of the delivered web services are used in the delivered business processes.

See Also

PeopleTools 8.52: PeopleSoft Integration Broker PeopleBook

Delivered Web Services

Oracle delivers web services for common CRM transactions (for example, customer, case, order, quote, service management, product, billing account, number management, agreement, service order, installed product, task, financial account, policy, claim, correspondence management, and so on) so that business processes can call these web services and be able to leverage CRM features that are readily available. External systems can use delivered web services to perform typical operations such as creating, updating transactions, and retrieving transaction information, each of which exists in the online system as well. Note that some web service operations may not provide the full functionality that is available in the online system. For example, the Create Task operation of the Task web service does not support the creation of recurring tasks. Refer to the appendix chapter in each application PeopleBook for more information about delivered web services.

Note. PeopleBooks provide functional descriptions of the web services (for example, list of operations and their descriptions) delivered by their applications. For technical information of these web services, refer to the web services documentation that is available after the installation of the application CD. Locate the Web Services Doc folder under %PSHOME% and open the index.html file in that folder to access information about various web services.

Service Operation Activation

As delivered, service operations in CRM-delivered web services are set to be inactive. You need to reactivate service operations for the web services that you use. To do so:

Note. The functional description of delivered business processes is available in the peoplebook of the corresponding application as an appendix chapter. This chapter references the web services that are used in each business process. For each business process you want to implement in your system, activate all service operations of the web services that are used in that business process.

1. Navigate to PeopleTools, Integration Broker, Integration Setup, Service Operations.

   Select the service operation you want to reactivate.

2. On the General page that appears, select the Active field.

3. On the Routings page, make sure that the routing (the one that has PSFT_WEB_SERVICE as the sender node) is activated.

4. On the Handlers page, make sure that the listed handler are activated.

   Most service operations have handlers; typically it is one for each service operation.

5. (For asynchronous service operations only) Navigate to PeopleTools, Integration Broker, Service Operations Monitor, Administration, Queue Status.

   On the Queue Status page, make sure that the queue that the service operation uses is in Running mode.

   You can find the name of the queue that an asynchronous service operation uses on the General page.

See Also

Order Capture Delivered Business Processes and Web Services

Delivered Web Service and Service Operations

Sales Delivered Business Processes and Web Services

Delivered Web Service and Service Operations for CRM Common Components

Delivered Web Services and Service Operations

Business Object Delivered Web Services

Product Delivered Web Services

Delivered Web Service and Service Operations

Delivered Web Services and Service Operations

Delivered Web Services and Service Operations

PeopleTools 8.52: PeopleSoft Integration Broker PeopleBook

PeopleTools 8.52: PeopleSoft Integration Broker Administration PeopleBook

Setting Up Business Process Security

This section discusses how to:

• Enable security for delivered business processes.

• Develop secured business processes.

Enabling Security for Delivered Business Processes

As a means to enforce security, delivered business processes are built to be invoked only by users that belong to the ECRM_BPEL role.

Important! The ECRM_BPEL role is defined in the Oracle Application Server or the BPEL Server but not in the PeopleSoft CRM system.

Oracle delivers this role and a user (ECRM_BPEL_USER) that belongs to this role in the BPEL server. Delivered business processes are secured—the initiation of these business processes is limited only to users who belong to the ECRM_BPEL role, and the instantiation of these business processes are done on behalf of the ECRM_BPEL_USER user. You can add a new user with the same role to be used in your environment as needed.

This procedure outlines the steps that are required to enable security for delivered business processes in any given BPEL domain. Some of them are performed at the BPEL server level and some are at the BPEL domain level.

Note. Make sure to perform these steps before the deployment of business processes on a domain.

Suppose that you have just created a new BPEL domain. Then:

1. Open the message-handlers.xml file of that BPEL domain.

   This file is located at <BPEL_Home>\bpel\domains\<BPEL domain name>\config. Note that changes made on this file impacts only the business processes that belong to this particular domain. Edit the file as follows:

   • Uncomment this property:

     <!-- uncomment for inbound security
              <message-handler id="" />
     -->
     

     This setting enables domain-wide security and needs to be done only on your local development servers. The central BPEL development server should already have this domain-wide security enabled.

   • Enable security at the business process level by adding the names of business processes that you want to secure in the value element. Suppose that you want to secure four processes: ProcessA, ProcessB, ProcessC, and ProcessD. Add them to the file like so:

     <!--
             <property id="">
                 <value>ProcessA,ProcessB,ProcessC,ProcessD</value>
             <comment>A list of secure process names, with names separated by⇒
      commas.</comment>
             </property>
     -->
     

     Make sure that this property is uncommented.

2. Add the ECRM_BPEL_USER user and the ECRM_BPEL role to the <BPEL_Home>\j2ee\oc4j_bpel\config\jazn-data.xml file (this is performed once on the BPEL server if you have the full server version), like so:

   		<user>
   			<name>ECRM_BPEL_USER</name>
   			<display-name>PeopleSoft Enterprise Integration User</display-name>
   			<description>User ID for activating secured services from within PeopleSoft⇒
    Enterprise</description>
   			<credentials>!ECRM_BPEL_USER</credentials>
   		</user>
   
   
   <roles>
   		<role>
   			<name>ECRM_BPEL</name>
   			<display-name>PeopleSoft Enterprise Integration Role</display-name>
   			<description>Secured Service Integration Role for PeopleSoft Enterprise<⇒
   /description>
   			<members>
   				<member>
   					<type>user</type>
   					<name>ECRM_BPEL_USER</name>
   				</member>
   			</members>
   		</role>
   [unchanged roles not listed]
   </roles>
   

   You can add a new user to be used in your environment if needed. Make sure this new user is a member of the ECRM_BPEL role. Refer to BPEL security in the Oracle BPEL Process Manager documentation for information on configuring users and roles.

   The password of the user is specified in this line (preceded by an exclamation point): <credentials>!ECRM_BPEL_USER</credentials>. Restarting the BPEL server encrypts the password in this file.

3. Add the user and the user role (as described in the above step) to the jazn-data.xml file under <BPEL_HOME>\integration\orabpel\system\appserver\oc4j\j2ee\home\config.

   This step is performed once on the BPEL server if you have the light server version.

4. Apply a BPEL tools patch.

   The patch number is 5139817.

5. Stop and start the Oracle Application Server and BPEL Process Manager.

6. On the CRM system, navigate to PeopleTools, Integration Broker, Integration Setup, Nodes. Open the BPEL node.

7. On the Node Definitions page, enter ECRM_BPEL_USER (or the new user you created) as the external user ID and the user password (specified in the jazn-data.xml file, ECRM_BPEL_USER in the above example) as the external password.

   Note. The user specified here must match the user that is specified for the ECRM_BPEL role in the jazn-data.xml.

8. On the WS Security page, select Username Token for the authentication token type and select the Use External User ID check box.

9. Deploy business processes using obant or Jdev.

Developing Secured Business Processes

This procedure outlines the steps needed to develop secured business processes.

Oracle delivers in the BPEL server a role (ECRM_BPEL) and a user (ECRM_BPEL_USER), a member of that role, which is used to invoke business processes. To secure business processes that you develop, make sure to:

1. Include the ECRM_BPEL role in the BPEL suitcase by clicking the Deployment Descriptor Properties button.

   On the Configurations tab, create the role property and enter ECRM_BPEL to be the property value. After the role property is added, the line <property name="role">ECRM_BPEL</property> is available on the BPEL.XML file:

   <?xml version = '1.0' encoding = 'UTF-8'?>
   <BPELSuitcase>
      <BPELProcess id="" src="SecureSyncCalc.bpel">
         <partnerLinkBindings>
            <partnerLinkBinding name="client">
               <property name="wsdlLocation">SecureSyncCalc.wsdl</property>
            </partnerLinkBinding>
         </partnerLinkBindings>
         <configurations>
            <property name="role">ECRM_BPEL</property>
         </configurations>
      </BPELProcess>
   </BPELSuitcase>
   

   By specifying this role property, any user who is a member of this role can invoke instances of this business process, as well as any service on any instance of this business process.

2. Open the message-handlers.xml file in $BPEL_HOME/domains/default/config.

   See step 1 in the Enabling Security for Delivered Business Processes section in this chapter for edits that need to be made.

3. Add delivered user and role to the jazn-data.xml file.

   See steps 2 and 3 in the Enabling Security for Delivered Business Processes section.

   See Enabling Security for Delivered Business Processes.

4. Repeat steps 4 to 9 in the Enabling Security for Delivered Business Processes section.

   See Enabling Security for Delivered Business Processes.

Setting Up CRM and BPEL Integration

To set up CRM and BPEL integration, use the Transaction Type (RBB_TRNSTYP_DFN) component.

To update business process end points, use the Update End Point Addresses (RBB_MSGUPD) component.

This section discusses how to:

• Specify unique transaction IDs.

• Update business process end points.

Page Used to Set Up CRM and BPEL Integration

Specifying Unique Transaction IDs

Access the Transaction Type page (Set Up CRM, Common Definitions, Business Process, Infrastructure, Define Transaction Types, Transaction Type).

As delivered in the CRM system, several common transactions are enabled to initiate business processes. Enabling additional transactions is a consulting effort and is not supported by Oracle.

Component Transfer Details

Information in this group box assists the CRM system to identify the appropriate association tables and transaction key values for the association. The system also uses this information to transfer users from the business process monitor or worklist outcome pages to the transaction page.

Updating Business Process End Points

Access the Update End Points page (Set Up CRM, Common Definitions, Business Process, Infrastructure, Update End Point Addresses, Update End Points).

In delivered business processes, a generic token (such as ID) is used to represent end points because end points refer to the BPEL Server from which business processes initiate, and the server is certainly different from one implementation to another.

Use this page to update the end points in delivered business processes by specifying a BPEL node.

Defining Business Process States

This section discusses how to:

• Define process states.

• Define activity states.

Pages Used to Define Business Process States

Defining Process Statuses

Access the Instance Details page (Set Up CRM, Common Definitions, Business Process, Infrastructure, Define BPEL States, Instance Details).

The BPEL Console maintains the states of business process instance using numeric codes and they are not descriptive. This page lists user-friendly names for various business process statuses as delivered in the system. The business process monitor uses these names to represent statuses of business processes that are executed by the BPEL Engine.

Defining Activity States

Access the Activity Details page (Set Up CRM, Common Definitions, Business Process, Infrastructure, Define BPEL States, Activity Details).

Enter user-friendly names for various activity states. The business process monitor uses these names to represent statuses of activities that occurred in external systems.

See Also

Monitoring Business Processes