Purging the Completed Composite Instances Syntactic Functional Validation of XML Messages

27-2 Developers Guide for Oracle Application Integration Architecture Foundation Pack situations in which the applications produce Application Business Messages ABM containing all of the elements regardless of whether the elements underwent change or not, the requester connector services should assume that the empty elements in ABM are not significant; and should ignore them when producing EBM. The first code example shown in Example 27–1 illustrates how this could be done. In situations in which ABMs contain only elements that underwent a change in value, the connector services should treat the presence of an empty element as the senders intent to have the consumer nullify the values for that element. Example 27–2 illustrates this use case. With service requesters producing EBM in the preceding manner, the job of the consumer becomes straightforward. It can assume that every element is a significant one-hence, the ABCS consuming the EBM should not skip the empty element. Example 27–3 illustrates how a message containing significant elements can be processed. Use the construct in Example 27–1 when the source applications ABM contains all the elements defined in its schema regardless of whether or not all those elements underwent any change in value. In this situation, in the interest of conserving memory, we make the assumption that an empty element is NOT a significant element and we ignore them. Example 27–1 ABM - EBM Transformation ~-- xsl:if test=ABMSourceElementtext EBMTargetElement xsl:value-of select=ABMSourceElement EBMTargetElement xsl:if Use the construct in Example 27–2 when the source applications ABM contains only those elements that underwent a change in value. In this situation, the presence of an empty element can be considered significant and so we do not ignore it. Example 27–2 ABM - EBM transformation ~-- xsl:if test=ABMSourceElementtext EBMTargetElement xsl:value-of select=ABMSourceElement EBMTargetElement xsl:if If the above rules have been followed, then we can assume that any empty element in the EBM is a significant one, and therefore should not be ignored when transforming from EBM to ABM. So use the construct in Example 27–3 . Example 27–3 EBM - ABM Transformation ~-- xsl:if test=EBMSourceElement ABMTargetElement xsl:value-of select=EBMSourceElement ABMTargetElement xsl:if

27.1.2 Purging the Completed Composite Instances

AIA highly recommends having a process in place to archive and clean up the completed composite instances after a specified period. ■ Synchronous request -response-based completed composite instances should be purged from SOA dehydration data store after a month. ■ Data synchronization-related composite instances should be purged three to four months after their completion. ■ Composite Business Processes should be purged one to two years after their completion. Best Practices for Designing and Building End-to-End Integration Flows 27-3 Even though this duration is subject to change based on your company policies, attempts should be made to do the purging at the earliest time. Purging must be preceded by archiving of the instance data. For more information, see in Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite.

27.1.3 Syntactic Functional Validation of XML Messages

This section discusses: ■ Section 27.1.3.1, Syntactic Validation ■ Section 27.1.3.2, Data Functional Validation

27.1.3.1 Syntactic Validation

With document style, a web service endpoint can use the capabilities of a validating parser and the run time to perform syntactic validation on business documents against their schema definitions. A schema specifies the data shape of the payload that could be sent to the web service operation. When a SOAP message is received by the web-services handler, the schema pertaining to the operation being called is used to validate the content of the SOAP message. Because this validation has a performance impact, it should be used judiciously in a production environment. AIA recommends enabling the schema validation only for the service-receiving message from a requester outside its boundary. Even though the requester could be an internal application, the syntactic validation is normally applied at run time only for messages coming from an external source. We highly recommend that you turn off schema validation for the intermediary services residing in AIA layer. In a development environment, we highly recommend that you turn on schema validation for all services during certain testing phases to ensure that messages produced by services are syntactically valid. For more information about how to enable schema validation, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

27.1.3.2 Data Functional Validation

AIA highly recommends that the validation be done by the service provider. It could be done either by the provider ABCS or by the application itself.

27.1.4 Provide Provision for Throttling Capability