webMethods and Intelligent Business Operations 10.2 | Integrating Cloud Applications | Administering CloudStreams | Cloud Connections and Services | Support for service signatures having complex nested document structures
 
Support for service signatures having complex nested document structures
For some back ends, the service signatures are very complex in nature. If those signatures are represented as document types, the document structures become very nested and deep. If such document structures are used to create service signatures, out of memory issues are observed. Therefore for such back ends, connector services could not be created.
In earlier releases, CloudStreams always concretized the document types that are referred to in the service signature and made a copy of the referred documents in line into the service signature. With this approach, service signatures could not be created for back ends with complex and deep signature structures, as loading those huge and nested document types resulted in out of memory issues.
For those types of back ends, you must use the Hybrid approach for creating connector service signatures. In this approach, a service signature is generated by combining reference of document types with concrete document types (optional). This approach only concretizes the signature path, which requires a hint to be applied. A hint is denoted by declaring a literal to XPath mapping, where the literal value is the hint that is intended to be applied on the end element of the XPath.
Sample Literal-XPath mapping
For example, if the following literal to XPath mapping is defined in the operation/resource definition, CloudStreams will concretize all the reference documents that occur in the given XPath mapping path, which is tns:AllowFieldTruncationHeader/tns:allowFieldTruncation.
<mappings>
<map context="IN" isRequired="true" isFixed="false" displayName="Field
Truncation Header" name="allowFieldTruncation">
<description>If this header value is true then it truncates data if the data
is too long and does not fit into the given field</description>
<source type="LITERAL">false</source>
<target type="XPATH" documentRef="wmSalesforceConnector_v31.doctypes:
Header_AllowFieldTruncationHeader">
<xpath>tns:AllowFieldTruncationHeader/tns:allowFieldTruncation</xpath>
</target>
</map>
</mappings>
Rest of the signature that does not have any hint to be applied will be rendered as a reference only. This helps you to reduce the foot print of the signature. In the absence of any hint or literal to XPath mapping, this approach leads to a service signature full of only document references.
To adopt the hybrid approach for connector service generation, you must make the following entry in the operation/resource level to create the signature:
<properties>
<property name="allowNSReferenceInSignature" value="true"/>
</properties>
Further, you must also configure the Document Expansion preferences with the recommended values mentioned in the Document Expansion Preferences section in the webMethods Service Development Help.
Note: This approach is not applicable for back ends where business object look ups are involved, for example, Salesforce CRM.

Copyright © 2015- 2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release