After the connections have been configured, processes may be defined and configured. As an administrator, you can access the connection configuration page by expanding the Administration menu, and then expanding the Oracle BPEL Administration folder. Click Process Configurations. The Process Configurations page is displayed.
This page contains Actions drop-down lists that provide the following choices.
|Add Process||Allows you to add an additional process configuration.|
|Configuration Information||Opens the Configuration Information page for the process configuration.|
|Update Process||Enables you to edit the BPEL process and operation.|
|Update Payload||Enables you to edit the mappings from content item fields to payload properties.|
|Delete Configuration||Enables you to delete the process configuration.|
|Test Connection||Allows you to test the JNDI Properties of the connection configuration.|
After you create a process configuration, you need to define process properties and payload mappings. See Process Properties for information on how to edit process properties. See Payload Mappings for information on how to edit field mappings.
Process properties identify the BPEL process and the BPEL operation used to initiate a new process. To edit process properties, choose Update Process… from the Actions menu. The Update BPEL Process page is displayed.
The fields on this page are defined in the following table.
|BPEL Process||The process identifier of a deployed, active BPEL process. Each active process is listed with the Process Name and Process Revision. The default revision for each process is identified with an asterisk (*).|
|BPEL Operation||The name of an operation to initiate a process.|
Payload mappings define how Content Server fields and literal values are mapped to payload properties to initiate a process.
To edit payload mappings, choose Update Payload from the Actions menu. The Update BPEL Process: Payload Mapping page is displayed.
This page displays a form with three columns. Each of the columns is defined in the following table.
|Field||The name of the payload element to which values are mapped.|
|Type||The type of payload element. This is used to filter the options displayed in the value option list. Complex types contain other types. If the type is an array of elements, then the value mapping may be a comma-separated list that is parsed by the component.|
|Mapping||Used to identify the name of a Content Server field. These fields are the standard Content Item fields (dID, dDocName, dDocTitle, etc.), custom information fields, and some special system fields. The possible special fields are:|
|HttpAbsoluteCgiPath - The absolute CGI path to the Content Server.|
|HttpAbsoluteWebRoot - The absolute path to the Content Server web root.|
|idcReference - Creates a string with a value of "socket:<HttpServerAddress>:<HttpServerPort>"|
|DocUrl - The computed URL to the web viewable file.|
|ContentViewLink - The computed URL to a content view page, showing a view of the content and links to content information.|
|@Literal - Allows you to assign a literal value. When this option is chosen, an additional text entry field is displayed to provide the value. You can enter array values using comma-separated notation.|
The following figure shows an example of field mappings.
On this page, the following mapping is established:
The taskId payload field is assigned the value of the content's dID.
The title payload field is assigned the value of the content's Title.
The creator payload field is assigned the literal value of sysadmin.
The UCM integration with BPEL requires that the BPEL composite has a binding.adf entry in its serivce. This binding allows UCM to invoke the BPEL as a service and allows it to set the conversation id to later query SOA for status.
Consequently, when creating a BPEL composite and making it available to UCM, the following must be done:
Open the composite in jdeveloper.
Open the composite.xml in source mode.
Find the service definition.
Add the following line to the service definition.
<binding.adf serviceName="YourUniqueServiceName" registryName=""/>
where the serviceName is something meaningful of your choosing and registryName must be empty.
A possible composite example is as follows:
<service name="receive" ui:wsdlLocation="receive.wsdl"> <interface.wsdl interface="http://oracle.com/sca/soapservice/aug11_app_2/myThirdComposite/receive#wsdl.interface(execute_ptt)"/> <binding.ws port="http://oracle.com/sca/soapservice/aug11_app_2/myThirdComposite/receive#wsdl.endpoint(receive/execute_pt)"/> <binding.adf registryName="" serviceName="my3rdBPELService"/> </service>
This can also be done using jdeveloper widgets, but they require a non-empty registryName. The registryName for a composite without adf is empty and the composite examples given here need the registry name to be empty. If they are not empty, API calls do not work properly after invoking the composite via the standard SOA.