9 Integrating Imaging with BPEL
This chapter has the following sections:
9.1 About Integrating Imaging with BPEL
For additional information on workflow integration points, connection configuration, security and fault reporting, see Integrating with a Workflow in Administering Oracle WebCenter Content: Imaging.
9.2 Invoking Imaging Web Services from a BPEL Process
One possible integration point between Imaging and BPEL is a service call into BPEL from Workflow Agent to create a new process instance using document metadata stored in Imaging. It is also possible for the BPEL process to make web service calls back to Imaging. Such calls can retrieve the latest document metadata, additional metadata, or update document metadata to synchronize changes made during the execution of the process instance.
Calls to any Imaging web service from BPEL will use the same general procedure:
9.3 Updating Imaging Metadata from a BPEL Process
As mentioned above, the transform definition from BPEL instance variables to Imaging web service input variables is a complex topic that is dependent on the specific schemas involved. However, because updating document metadata is a common use case for BPEL to Imaging interaction, Example 9-1 shows how the transform might be defined for a DocumentService.updateDocument operation used to modify document field values.
Example 9-1 Invoking DocumentService.updateDocument Sample
In this example, a purchase order document is indexed into Imaging and a BPEL process instance is created in an approval process. During the execution of the approval process, the instance is approved or denied. At the end of the process, Imaging needs to be updated with the approval status and the name of the user setting the status. This example assumes the following configuration.
Application Definition contains the following fields:
-
PurchaseOrder: id=1, type string
-
ApprovedBy: id=2, type string
-
ApprovedStatus: id=3, type string
The BPEL Process variable is defined as follows:
<element name="process"> <complexType> <sequence> <element name="docId" type="string"/> <element name="docURL" type="string"/> <element name="poNumber" type="string"/> <element name="approvedBy" type="string"/> <element name="approvedStatus" type="string"/> </sequence> </complexType> </element>
An external partner link is defined using the document service WSDL:
http://host:port/imaging/ws/DocumentService?wsdl.
The updateDocument operation payload type is defined as follows:
<xs:complexType name="updateDocument"> <xs:sequence> <xs:element name="documentId" type="xs:string" minOccurs="0"/> <xs:element name="uploadToken" type="xs:string" minOccurs="0"/> <xs:element name="fieldValues" type="tns:FieldValue" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="updateAnnotations" type="xs:boolean"/> </xs:sequence> </xs:complexType>
For modifying document field values, the elements that are significant are the documented elements and the fieldValues element. The FieldValue type and the type's references are defined as follows:
<xs:complexType name="FieldValue"> <xs:complexContent> <xs:extension base="tns:baseId"> <xs:sequence> <xs:element name="value" type="tns:TypedValue" minOccurs="0"/> </xs:sequence> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="id" type="xs:long" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="TypedValue"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" type="tns:FieldType"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:simpleType name="FieldType"> <xs:restriction base="xs:string"> <xs:enumeration value="TEXT"/> <xs:enumeration value="NUMBER"/> <xs:enumeration value="DECIMAL"/> <xs:enumeration value="DATE"/> </xs:restriction> </xs:simpleType>
Although the XSD for FieldValue looks rather complicated, the following sample XML instance of FieldValue demonstrates that it is actually fairly simple.
<fieldValues name="ApprovedStatus", id="3"> <value type="TEXT"> APPROVED </value> </fieldValues>
The name and ID attributes in the fieldValues node are the name and ID of the document field value to be modified. In practice, providing one or the other is enough to identify the field. The value element provides the new value of the document field, and the type attribute, which is one of TEXT, NUMBER, DECIMAL, or DATE) indicates the Imaging type of data being provided.
The updateDocument type XSD indicates that the fieldValues has an unbounded maxOccurs attribute. In fact, the service expects that there be one instance of the element for each document field value that is being modified. Field Values that are not being modified need not be supplied.
Finally, the XSL transform in the BPEL process must assign the docId element from the BPEL instance variable to the documentId node in updateDocument and transform the ApprovedBy and ApprovedStatus values in the BPEL process variable into two FieldValue elements. The transform is defined as follows:
<xsl:template match="/"> <tns:updateDocument> <documentId> <xsl:value-of select="/client:process/client:docId"/> </documentId> <xsl:for-each select="/client:process/client:approvedBy"> <fieldValues> <xsl:attribute name="name"> <xsl:text>ApprovedBy</xsl:text> </xsl:attribute> <value> <xsl:attribute name="type"> <xsl:text>TEXT</xsl:text> </xsl:attribute> <xsl:value-of select="/client:process/client:approvedStatus"/> </value> </fieldValues> </xsl:for-each> <xsl:for-each select="/client:process/client:approvedStatus"> <fieldValues> <xsl:attribute name="name"> <xsl:text>ApprovedBy</xsl:text> </xsl:attribute> <value> <xsl:attribute name="type"> <xsl:text>TEXT</xsl:text> </xsl:attribute> <xsl:value-of select="/client:process/client:approvedStatus"/> </value> </fieldValues> </xsl:for-each> </tns:updateDocument> </xsl:template>