Fusion Apps Integration Patterns WP

An Oracle White Paper
February 2012
Integrating with Fusion Applications

- Overview of Design Patterns
Integrating with Fusion Applications Overview of Design Patterns
Disclaimer
The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing decisions. The development, release, and
timing of any features or functionality described for Oracles products remains at the sole discretion of
Oracle.
Executive Overview ........................................................................... 1

Introduction ....................................................................................... 1
Integration Design Patterns ............................................................... 2
Inbound: Calling Fusion Applications Web Services ...................... 2
Outbound: Calling External Applications ...................................... 11
Event Notifications using CRM Outbound Messages ................... 23
Invoking Custom CRM Business Processes for Integration ......... 25
SCM Distributed Order Orchestration: External Interface Layer ... 27
Bulk Import: Importing Data in Fusion Apps ................................. 27
Bulk Export: Exporting Data from Fusion Apps ............................ 29
UI Level Integrations.................................................................... 31
Conclusion ...................................................................................... 32
Glossary .......................................................................................... 32
Executive Overview
Fusion Applications provides various ways for integrating its functional capabilities with other
Oracle applications as well as 3rd party and legacy applications. This paper provides an
overview of integrating Fusion Applications with Oracle SOA Suite, specifying best practice
design patterns for safe upgrades, as well as integration examples to highlight their usage.
Introduction
The primary focus of this document is to describe how to build custom integrations to Fusion
Applications for on-premise and managed hosted deployments. It does not cover functional
design or business process analysis, which is assumed to be done in the tool of choice.
This paper also assumes knowledge of discovering integration artifacts (termed as assets)
such as web services, business events, interface tables, flat files and others in the Oracle
Enterprise Repository (OER). For more information on using OER, refer to the white paper
entitled Making the most of Oracle Enterprise Repository for Fusion Applications.
The following sections provide an overview of using different message exchange patterns with
the integration artifacts to provide the recommended integration patterns.
1
Integration Design Patterns

The macro SOA patterns used in Fusion Applications is shown below.
Figure 1: Fusion Macro Patterns using SOA
This section discusses the various service interaction patterns used by the integration assets.
Inbound: Calling Fusion Applications Web Services
Invoking ADF Services
ADF services can be invoked in various different design patterns: synchronous request-reply
invocation, asynchronous request-reply, using Web Service binding or SDO binding, or via BPEL
Entity Variables. The recommended design pattern to invoke ADF services is via web service binding.
Figure 2: ADF Service Call
2
Oracle Fusion web applications often include long-running services exposed through service interfaces.
Invoking such services through a synchronous service interface may not execute as desired due to time
outs or lack of resources as a result of blocked, waiting threads. To solve this problem, invoke the
service through asynchronous interfaces that wait for a response.
The recommended approach to asynchronous invocation is to create an asynchronous SOA composite
with a BPEL process that invokes the asynchronous service. The client BPEL process invokes an
asynchronous service through the WSDL partner link. The service runs as required, and returns a
response to the waiting client BPEL process.
ADF-BC web services support both synchronous and asynchronous request-reply methods of
invocation, although it is up to the individual services to enable the asynchronous methods. Refer to
the service description in OER to view if there are asynchronous operations enabled. These operations
have names that are suffixed with Async and AsyncResponse. To provide the asynchronous capability,
Fusion Applications web services use the database Advanced Queue (AQ) feature, as shown below.
Figure 3: Asynchronous Web Service Call
The following describes the flow shown in the previous figure:

1. The client calls an asynchronous method.
2. The asynchronous Web service receives the request and stores it in the request queue.
3. The asynchronous Web service sends a receipt confirmation to the client.
4. The MDB listener on the request queue receives the message and initiates processing of the request.
5. The request MDB calls the required method in the Web service implementation.
6. The Web service implementation returns the response.
7. The request MDB saves the response to the response queue.
8. The request MDB sends a confirmation to the request queue to terminate the process.
3
9. The onMessage listener on the response queue initiates processing of the response.
10. The response MDB, acting as the callback client, returns the response to the callback service.
11. The callback service returns a receipt confirmation message.
12. The response MDB returns a confirmation message to the response queue.
The table below shows the request/response queues shipped with Fusion Applications, which can be
used by administrators for monitoring or diagnostics.
CRM_AsyncWS_Request CRM_AsyncWS_Response
HCM_AsyncWS_Request HCM_AsyncWS_Response
FIN_AsyncWS_Request Fin_AsyncWS_Response
PRC_AsyncWS_Request PRC_AsyncWS_Response
PRJ_AsyncWS_Request PRJ_AsyncWS_Response
SCM_AsyncWS_Request SCM_AsyncWS_Response
IC_AsyncWS_Request IC_AsyncWS_Response
COMMON_AsyncWS_Request COMMON_AsyncWS_Response
The SOA runtime handles web service callback correlation automatically using WS-Addressing.
Invoking Composite Web Services
Composite web services can be invoked in a synchronous request-reply, asynchronous request-reply as

well as asynchronous one-way pattern. Many composite services will typically be asynchronous, given
the nature of back-end processing use cases and the default configuration of the components e.g.
BPEL.
ADF services and other clients such as ESS jobs can invoke composite web services by invoking the
service endpoint, or by raising an event to which the composite has subscribed to. The latter pattern of
raising business events from ADF to invoke composite services is the recommended design pattern
used by Fusion Applications and is shown below.
Figure 4: Recommended pattern for invoking composites from ADF
4
Note that in the pattern above, while it is possible for the BPEL process to directly subscribe to the
events, the Mediator provides a level of abstraction and increases reusability of the BPEL process. For
more information, refer to the Fusion Applications Developers Guide.
Primary Key Management
When integrating with external systems, transactional ADF services typically use surrogate keys (e.g.
internal IDs) to uniquely identify the data. Non-transactional services such as those used for setups
may utilize user-identifiable keys for the same purpose. In both cases, the keys used in Fusion
Applications may need to be cross referenced with keys from external systems. The cross reference of
the keys can be done in various ways:
Store cross references in Fusion Applications: In this approach, Fusion Applications stores the cross
reference of the keys with external systems. For example, the Distributed Order Orchestration
application stores the upstream as well as downstream application specific object instance identifiers in
its data store. The application can then send the Fusion Application or external system identifiers in
the web service payloads. This is the recommended approach for integrating with Fusion Applications.
Store cross references in external systems: This approach is similar to the one above, except that the
cross reference data is stored in an external system being integrated with Fusion Applications.
Store cross references in Fusion Middleware: There is a cross reference functionality built in the Fusion
Middleware SOA Suite stack, which can be used for cross-system integrations. This is useful when
interoperating with older applications which may not have any built-in cross reference capability.
Metadata Extensibility
Fusion web services store the service operations and messages in the WSDL file, and the associated
schemas are stored in separate XSD files. The schema files are downloaded automatically by the
development tools such as JDeveloper when generating the web service proxies.
Customizations made to ADF-BC objects using Key/Descriptive FlexFields or the Application
Composer are automatically updated in object schema files residing in MDS. These updated files need
to be re-downloaded, if an earlier, non-customized version was used to generate web service clients.
Since FlexField metadata are stored in ADF-BC MDS, any changes need to be propagated to the SOA
Server MDS, so that the extended attributes are available in the SOA composite (e.g. in business rules).
Figure 5: Syncing ADF MDS with SOA MDS
5
This is done by an ADF MDS listener that raises an event upon a FlexField update. The event payload
contains the namespaces of the updated XSDs and it triggers the updateSOAMDS composite on the
SOA server, which copies the updated XSDs from the ADF MDS to the SOA MDS, as shown above.
Changes made from CRM Application Composer are also synchronized with the SOA MDS server.
The updateSOAMDS composite can also be invoked manually via Enterprise Manager to sync the
updated metadata. Use the updateDuring operation where you can input an xsd:duration, for example
"P1M2DT3H" will sync changes that happened during the last 1 month 2 days and 3 hours.
Alternately, use the updateSince operation, where you can input an xsd:dateTime; for example 2011-09-
10T09:00:00 will sync changes since that time. The list of files synced is returned in the response.
Once the metadata is updated on the SOA server, the Rules engine triggers a regeneration of the JAXB
objects based on the updated schema.
Accessing Extended Attributes at Runtime
Customer projects typically require extensions to the base objects, for example, adding new attributes
to an ADF business component via FlexFields. These customizations are reflected in the XSD schema
files and web services, and this metadata may be required in integration projects.
The customer deployed OER instance provides the base metadata along with links to the concrete
WSDL and XSD that has been customized for that implementation. (Note that the public OER
instance hosted at Oracle only contains the base metadata shipped by Oracle.) The customized WSDLs
honor the base WSDL interfaces; hence partners can use the base WSDL and XSD to build value-
added applications and integration offerings that need to work against any customer implementation.
These partner solutions can then be deployed against the runtime concrete WSDLs of a customer
implementation, where they may need to access extended attributes such as Key, Descriptive or
Extensible FlexFields. For example, when setting up Items, one customer may setup Color as a
Descriptive FlexField, whereas another customer may add Weight and Dimension as context
segment driven attributes. The integration solution would have developed against the base Item
attributes, but may still need to access the Color or other extended attributes where needed.
The recommended pattern to access the extended attributes at runtime is via their encapsulating XML
node elements. Consider the use case wherein a partner developed integration needs to copy data into
specific Fusion Applications FlexFields. Partners should build base integration transformation scripts
using call-outs to extension templates at the nodes where the FlexFields are expected. This is shown in
the XSL code snippet below.

<ns3:j_ItemEffCategory>
<xsl:call-template name="Item_Extn_Template"/>
</ns3:j_ItemEffCategory>
The customer then implements the extension template to map the specific extended attribute that
signifies Color, as shown below.
<xsl:template name="Item_Extn_Template">
<xsl:if test="/ns4:Color">
<ns3:ItemSpecificationCategory>
<ns3:featuresContext>
6
<ns3:color>
<xsl:value-of select="/ns4:Color/>
</ns3:color>
</ns3:featuresContext>
</ns3:ItemSpecificationCategory>
</xsl:if>
This design pattern removes the need for any specialized, loosely-typed interface for partners; both
customers and partners use the same interface for the web services.
Security
Fusion Applications web services are secured using Oracle Web Services Manager (OWSM) using the
WS-Security 1.1 standard, as shown in the diagram below.
Figure 6: Fusion Applications SOA Security Points
ADF Services enforce authentication and authorization policies (A1 and A2 in the diagram above), and
in some cases will also have data security enabled to restrict what is visible based on a users privileges.
SOA Composite services enforce authentication policies only (A1 in the diagram above).
Services that can be invoked outside of the Fusion Applications environment are tagged in OER with a
keyword of EXTERNAL and are provisioned to be accessible by external web service clients. These
services typically enforce a policy that uses either username token or SAML identity propagation with
message protection using SSL or WS-Security. Services that can only be invoked within the Fusion
Applications domain enforce a similar policy, but with no message protection required.
7
Some Fusion Applications web services are protected with authorization and/or data level security that
require higher privileges than the user calling the service. For example, a data synchronization project
between CRM and HCM requires privileges on both CRM and HCM data update services, something
that neither a typical CRM nor HCM user will have. Similarly, HR transactions may trigger back-end
processes that require access to Personally Identifiable Information (PII) or to sensitive transactions
(e.g. updating salary) that the logged in HR user should not have direct access to. Such services are
typically not externally available due to the intrinsic need for elevated privileges.
In the use cases above, using identity propagation with SAML tokens will result in security errors since
the current user will not be able to execute the web service or get access to the data required for
successful completion of the transaction. To address these security needs, Fusion Applications uses
application identities, which are similar to user identities, but are members of roles that have elevated
privileges compared to the calling user identity. For example, an application identity may be created
specifically for the purpose of the CRM and HCM synchronization project and another one for
accessing sensitive HR services and PII data. Fusion Applications ship with seeded application
identities for each pillar and technology named <Application>_SOA_APPID-KEY that have been
setup with the privileges and roles needed by the secured services.
Web service clients (identified as Client in the diagram with the lock icon) consuming Fusion
Applications web services need to attach policies that are compatible with the type of service being
invoked in order to successfully invoke the services.
External services: To invoke services available from outside Fusion Applications environments
(i.e. services marked as EXTERNAL in OER), use a SAML based security policy for identity
propagation with message protection i.e. wss11_saml_token_with_message_protection_client_policy.
Internal services: To invoke services available from inside Fusion Applications environments (i.e.
services not marked as EXTERNAL in OER), use a SAML based security policy for identity
propagation with no message protection i.e. wss10_saml_token_client_policy.
Protected services requiring elevated privileges: To invoke services requiring elevated
privileges, use the username token based security i.e. wss_username_token_client_policy. If the
protected service is available externally, use the username token based security with message
protection i.e. wss11_username_token_with_message_protection_client_policy. Since the overall transaction
will involve orchestrating many services, some of which may require elevated privileges, it is
recommended to use SAML token with identity propagation by default and only resort to
switching to application identity using username token for the specific services that require it.
Implementing identity switching in a BPEL process can be done by attaching the above named
policies to the BPEL partner link and configuring the policy to use a specific credential store key
(csf-key) pointing to the required application identity. For more details, refer to Oracle Fusion
Applications Developers Guide section on Implementing Fusion Security Application Identities.
Although any WS-Security 1.1 compliant web service client toolkit can be used to successfully invoke
Fusion Applications web services, Fusion Middleware provides the OWSM agent capability to achieve
the same. With OWSM, a keystore stored on the client machine is referenced by the client to
8
access the user alias, keys and values required for authentication to Fusion Applications. The public
certificate for Fusion Applications can be imported to the keystore, as shown below.
$ keytool -importcert -alias orakey -file oraclecertificatefile.cer -keystore ./oracle-
keystore.jks -storepass <keystorepassword>
$ keytool -list -keystore ./oracle-keystore.jks
The Java code snippet below (from the Fusion CRM Web Services Guide) shows a sample
authentication code to connect to a Fusion CRM Opportunity web service using the
Username/Password policy.
//Specify the policy
SecurityPolicyFeature[] securityFeature =
new SecurityPolicyFeature[] { new SecurityPolicyFeature
("oracle/wss11_username_token_with_message_protection_client_policy") };
OpportunityService opportunityService =
opportunityService_Service.getOpportunityServiceSoapHttpPort(securityFeature);
WSBindingProvider wsbp = (WSBindingProvider)opportunityService;

Map<String, Object> requestContext = wsbp.getRequestContext();
//Specify the keystore details

requestContext.put(ClientConstants.WSSEC_KEYSTORE_TYPE, "JKS");
requestContext.put(ClientConstants.WSSEC_KEYSTORE_LOCATION, "./oracle-keystore.jks");
//Password to access Keystore file

requestContext.put(ClientConstants.WSSEC_KEYSTORE_PASSWORD, "pass");
//Public key from Server for signing and encrypting

requestContext.put(ClientConstants.WSSEC_RECIPIENT_KEY_ALIAS, "orakey");
//Username and password to access the Fusion CRM instance

requestContext.put(WSBindingProvider.USERNAME_PROPERTY, "username");
requestContext.put(WSBindingProvider.PASSWORD_PROPERTY, "password");
Apart from WS-Security based message protection policies, web service endpoints are usually protected
at the transport layer using SSL. The incoming requests require the Web Logic Server (WLS) to be
setup to receive requests over SSL. In addition, when invoking an asynchronous Fusion Applications
web service using two-way SSL, the outgoing responses to the callback service needs the keystores to
be setup for SSL. Refer to the chapter on Securing SOA Composite Applications section
Configuring SOA Composite Applications for Two-Way SSL Communication in the Fusion
Middleware Administrators Guide for SOA for more details on the setup needed.
For further information regarding the web services security policies, please refer to the Oracle Fusion
Middleware Security and Administrator's Guide for Web Services 11g Release 1 and Fusion
Applications Security Hardening Guide.
Versioning
All Fusion Applications web services that have been marked in OER as assured for backward
compatibility, will maintain backward compatibility in future releases of the applications. In case any
non-backward compatible changes are needed, these will be released as new services with the version
9
number specified at the namespace level e.g. V2. For backward compatible service changes, the
WSDLs between the changes can be identified if needed by looking at the service provider Fusion
Applications rollup patch (RUP) level, since these changes are only made in a rollup patch.
Service version documentation is available in OER. For customer deployments, OER will only have
the tip version of the service since that is what is active and available in the system. The public hosted
OER deployments may host multiple versions of the services.
Handling Faults in Composite Service Instances
In the case of asynchronous composite services, any faults encountered by the service would need to
be recovered. BPEL faults can be recovered using the Recovery console in Enterprise Manager.
Recovery involves retrying the transaction from the last commit point wherein the composite process
state was saved to the database. While in many cases this retry is acceptable, in some cases where the
composite service invokes a custom web service (for example, a custom ADF service), the behavior of
the web service may not be suitable for retry. If a service does not yield the same behavior given the
same input, it is called as a non-idempotent service. For example, consider an HR composite service
invoking a custom ADF service that increases the salary by 10%. If any activity of the composite
service fails AFTER it has invoked the ADF service, the composite service state will roll back to its last
commit point before the ADF service, however the effects of the ADF service will not be rolled back.
Therefore, upon retry via the composite instance recovery, the ADF service will be re-invoked and it
will again increase the salary by 10%. This is shown in the diagram below.
Figure 7: Retry of Non-Idempotent Services on Recovery
During design, this kind of non-idempotent behavior should be avoided; for example in the above
case, the custom ADF service should simply update the object with the new salary value, so that any
retry would result in the same value being overwritten. Alternately, implementers should mark the
invocation of such web services as non-idempotent (during design time in BPEL partner-link
properties) or handle faults explicitly so that the activity is not retried. Such handling of non-
idempotent services at design time allows administrators at runtime to freely attempt recovery of
faulted services without any functional consequences. It also allows administrators to safely enable
auto-recovery options instead of performing manual recovery.
10
Best Practices for Fusion Applications Web Services
Below are some tips and best practices for invoking Fusion Applications web services. These are
generic best practices and are not specific to any given application web service.
Use the asynchronous methods for any calls that expect to take more than a few seconds or if you
expect to pass in a list of Service Data Objects. Unless you are certain that the service call will be short
running under normal operating circumstances, regardless of data size, use asynchronous methods.
Since most web services support multi-row payloads, it is difficult to guarantee a short running web
service; hence the default suggestion is to use asynchronous. If invoking an ADF Service from SOA,
default to using asynchronous unless there is an exceptional need to make a synchronous call.
For guaranteed message delivery, consider use of a messaging infrastructure, such as EDN or native
JMS (if the client does not use Fusion Middleware). Using such an infrastructure, with the ability to
retry using an exponential back-off, can result in a robust infrastructure resilient to any unplanned
downtime.
Fusion Web Services are organized in a granular fashion with schema information abstracted from the
methods/operations of the Web Service. Instead of manually downloading each XSD file referenced in
the WSDL, obtain the WSDL URL for the service from OER and use JDeveloper to import it, which
will resolve references to the schema files and download them.
To effectively manage service metadata (WSDL/XSD/EDL) in large scale integration projects, use the
Centralized Asset pattern, in which all integration metadata across all projects are stored in a
centralized location for easy access. This centralized location could be a shared network drive, a
development Fusion Applications instance (using concrete URL) or its Metadata Services (MDS). The
metadata is still accessed via the concrete WSDL obtained from the central development instance OER
and is referenced using HTTP protocol e.g. http://<host>:<port>/<path_to_asset>. If the
integrations are developed using Fusion Middleware, you can also access the metadata directly from
MDS of the development Fusion Applications instance using the ORAMDS protocol e.g.
oramds://<path_to_asset>. At deployment time, config plans should replace any references to the
development instance with the appropriate URLs for the production instance. This is the approach
used within Fusion Applications development.
For more details, refer to the Oracle Fusion Applications Developers Guide and the Oracle Fusion
Applications Administrators Guide section on Troubleshooting SOA.
Outbound: Calling External Applications

Integrations between Fusion Applications and external third party systems may be required to address
business requirements that span across multiple business areas. For example, the Distributed Order
Orchestration application needs to invoke external systems (e.g. Oracle E-Business Suite) to complete
fulfillment of a sales order. Similarly, the HR Talent Management application needs employee data to
be sourced from an external system (e.g. PeopleSoft Enterprise). Integration with industry specific
systems may also require call-outs from Fusion Applications.
11
Outbound web service calls may be needed from totally new/custom processes, or it may be needed as
extensions to existing Fusion Applications. For extensions to Fusion Applications, some applications
may have their own approaches to making external invocations. Some examples include:
Fusion CRM Applications provide a mechanism to send outbound messages via Object Workflows,
which allows events to trigger outbound message notifications based on changes to a business object.
Fusion SCM DOO application provides a web service interface to implement, which will receive
fulfillment order status notifications.
Where available, the native application integration approach should be utilized for external integrations.
In all other scenarios, the recommended approach is to trigger SOA composites using business events
from the ADF web application, and have the SOA composite invoke the external web service.
Raising Custom Business Events
The recommended design pattern for external web service invocation depends on the composite
subscribing to a business event of interest. If the business event has not been defined in the ADF
Entity Object event points out of the box, then the first step is to define the business event by creating
the event definition (.edl file) and the event payload (.xsd file) based on the service data object.
The next step is to identify the trigger point where the custom business event can be raised. During a
new ADF Entity Object definition, developers can associate an event with an event point e.g. Create,
Read, Update or Delete (CRUD). However, customers cannot customize the Entity Object to
declaratively associate new or custom events at those event points. Instead, use JDeveloper in
Customization Mode to add/modify trigger points in the ADF Entity Object with Groovy code to raise
the event. Use the BeforeCommit trigger point if there is a JTA transaction; otherwise raise the event in
the AfterCommit trigger point. The following ADF Entity Object XML code snippet shows an
example of a trigger point raising an event. Note that this is an 11g R1 PS5+ feature.
<Trigger Name="BeforeCommit">
<validation:ExpressionValidationBean
Name="BeforeCommitInDB"
OperandType="EXPR"
Inverse="false">
<validation:TransientExpression>
<![CDATA[myclass.raiseEvent(.....); return true;]]>
</validation:TransientExpression>
</validation:ExpressionValidationBean>
</Trigger>
Trigger points are more generic than the declarative CRUD style event points as they are not limited to
event publications and can be used for adding business logic, validations, logging etc. For this
integration use case though, we have only focused on the ability of the trigger points to raise business
events. In the example above, Groovy snippet invokes a custom Java class that should be coded to raise
the business event. For more details on raising events in Java, refer to the Oracle Fusion Applications
Developers Guide section on Initiating a SOA Composite from an Oracle ADF Web Application. For
more information on creating business events, refer to the Oracle Fusion Middleware Developers
Guide for Oracle SOA Suite.
12
Invocations from New or Customized Processes
The recommended pattern for outbound calls is to have a composite subscribe to the business event of
interest, similar to the recommended pattern for inbound invocation of composite services. The
composites mediator component could then be customized with content based filters in the routing
rules that can invoke different external web services via OSB, BPEL or BPM processes. Use the
following steps to implement an outbound web service call.
Using Composite editor in JDeveloper, add Web Service Reference to the WSDL endpoint of the
external service. Use abstract WSDL in import and provide a concrete WSDL in the binding.
Figure 8: Add Web Service to Composite in Jdeveloper
Add the reference to the external web service as Partner Link in a BPEL process.
Figure 9: Add Partner Link in BPEL
13
Add a routing rule in Mediator to invoke the BPEL component that makes the web service call.
Figure 10: Add Routing Rule in Mediator
For integration with external non-web services, use available technology or application adapters e.g.
JMS, file or EBS adapter etc. The adapters wrap heterogeneous applications or technologies that use
different interfaces, protocols and data formats, and expose them as standards based web services.
Figure 11: Use Technology or Application Adapters
14
To ensure that the remote service processes messages once and only once, considering using standards
such as WS-ReliableMessaging. Alternately, if it is possible to influence the web service interface (e.g.
for internal applications), consider including an additional unique message identifier with the web
service invocation. The web service should then ensure that it only handles the message identifier only
once, even if it receives it multiple times due to any network error. The unique message identifier can
be generated by using the BPEL instance id (using ora:getInstanceId()) or component instance id
(using ora:getComponentInstanceId()) and concatenating it with a suffix for the specific web service
invocation within the BPEL process.
Invocations from pre-built composites using Dynamic Partner Links
When designing composites that invoke endpoints which are not known at design time it is necessary
to have a predefined set of interface artifacts against which you can build your functionality. This is
often the case with pre-packaged applications such as Fusion Applications; however this pattern can be
used with customized composites as well.
For example, the Fusion SCM DOO application provides a pre-built composite (DOO Decomposition
Order Status Update Composite) for this purpose to communicate order status updates to downstream
systems, for which the endpoint URLs are not known in advance until they are implemented at a
customer site. The payload to the composite contains the primary keys and the status codes. Additional
data to pass to the external systems can be retrieved using GetFulfillmentOrderDetails web service.
In this design pattern, while abstract WSDL's and XSD's can support design-time requirements,
concrete artifacts need to be available at runtime. Since Fusion Applications provisioning doesn't use
config plan tokens for external URLs, one approach is to implement the outbound calls by including
concrete artifacts with dummy endpoint values that are overridden at runtime via Dynamic Partner
Link pattern or binding property. This is what Fusion Applications does.
The Dynamic Partner Link pattern allows a developer to design a BPEL process to determine the
service endpoint at runtime before invoking the service thereby allowing the BPEL process to invoke
services in different locations as long as they all share the same interface.
To resolve runtime WSDL dependencies without hosting a proxy composite, insert a placeholder in
the WSDL replacing the soap:address value with a literal value as shown in the example below.
Before:
<wsdl:service name="bpelprocess1_client_ep">
<wsdl:port name="BPELProcess1_pt" binding="client:BPELProcess1Binding">
<soap:address location="http://dev.mycompany.com:7777/soa-
infra/services/default/Project1/bpelprocess1_client_ep"/>
</wsdl:port>
</wsdl:service>
After:
<wsdl:service name="bpelprocess1_client_ep">
<wsdl:port name="BPELProcess1_pt" binding="client:BPELProcess1Binding">
<soap:address location="REPLACED_AT_RUNTIME_BY_DYNAMIC_PLINK"/>
</wsdl:port>
</wsdl:service>
This value will then be replaced with the actual value by dynamically passing in the URL at runtime.
15
External Service Invocation without Dynamic Partner Links
Without dynamic partner links, the endpoint is fixed but can be reconfigured either through EM,
Customization, or redeployment of the composite using config plans.
This pattern is identical to the Dynamic Partner Link case with one exception - instead of overriding
the WSDL endpoint with a BPEL Assign activity to the Partner Link's endpoint address values, the
endpoint value is fixed in the composite metadata for the service reference binding. The value is then
be overridden at deployment time through configuration plan or modified in Enterprise Manager.
This is done by manually setting the endpointURI property on the binding which can later be modified
in EM by the customer (or through a custom config plan) to a value like
http://service.host.name.domain:service.port/<service_context_root>/<service_name>
Example:
<binding.ws
port="/oracle/adfbc/async/sample/model/common/#wsdl.endpoint(AsyncADFHelloWorld/AsyncAD
FHelloWorldSoapHttpPort)"
location="AsyncADFHelloWorld.wsdl" soapVersion="1.1">
<property name="callbackServerURL" type="xs:string" many="false">
http://your.soa.host.domain:your_soa_port</property>
<property name="endpointURI" type="xs:string" many="false">
http://service.host.name.domain:service.port/AsyncADFHelloWorld-context-
root/AsyncHelloWorld</property>
<property name="weblogic.wsee.wsat.transaction.flowOption"
type="xs:string" many="false">WSDLDriven</property>
</binding.ws>
To modify the above property via deployment plan configuration, modify the configuration plan and
add the entries to replace the endpointURI property as desired. This is shown in the example below.
Use this configuration plan to deploy your composite either from JDeveloper or ant commands.
<?xml version="1.0" encoding="UTF-8"?>
<SOAConfigPlan xmlns="http://schemas.oracle.com/soa/configplan">
<composite name="OverrideAsyncCallback">
<reference name="AsyncHelloWorld">
<binding type="ws">
<property name="callbackServerURL">
<replace>http://prod.mycompany.com:8080</replace>
</property>
<property name="endpointURI">
<replace>http://prod.mycompany.com:7001/WFClientPatternApp-Project2-
context-root/AppModuleService</replace>
</property>
</binding>
</reference>
</composite>
</SOAConfigPlan>
To modify the property via Enterprise Manager, go to the composites property page as shown below.
Click on the composite nameSOA Composite (contextual menu) Service/Reference
PropertiesSelect reference to modify.
16
Figure 12: Changing a Service Reference Endpoint URI using Enterprise Manager
Outbound web service calls also have some special considerations, which are noted below.
Event payloads for outbound integrations typically contain minimal contextual information, for
example primary keys, which the external system should use to make inbound calls for enriching data.
The secure nature of Fusion Applications topology requires asynchronous web service callback address
to be properly configured to the external/public HTTP server address (covered later in this section).
If events produced by Fusion Applications are at a much finer level of granularity than those needed by
external systems, then these events may need to be collated. This can be done using an Aggregator
Producer design pattern wherein an intermediary service queues up the events and raises a coarse-
grained event that is then published. The discussion of this design pattern is out of scope of this paper.
Security for External Web Service Invocation
Fusion Applications invocation of external services should be configured to use client OWSM policies
using message protection with SAML or username token. Message protection can be implemented
using 1-way SSL, 2-way SSL or WS-Security tokens, depending on the security and performance needs.
Using SSL based policies relies on transport layer security to provide message protection. This may
provide maximum interoperability when invoking external, third party services, which may not have
WS-Security based message protection capabilities or may not be able to advertise their public
certificates in the WSDLs, thereby requiring configuration of keystores within Fusion Applications.
Receiving Asynchronous Callbacks from External Systems
Outbound web service calls that expect a callback from systems external to Fusion Applications have
some special security considerations. This section explains the Fusion Applications deployment
topology in a secured environment to highlight this.
The Fusion Apps topology splits visibility to web and service resources into two categories - internal
and external. This is achieved by fronting all HTTP requests through two different Oracle HTTP
17
Servers (OHS), one for internal traffic routed between Fusion Applications servers, and another for
external sources, which has only a small subset of the routing rules to prevent unauthorized access by
external systems. This approach facilitates unhindered access within the Fusion Applications domain
set and restricts access to outside systems. The high level topology is shown in the diagram below.
Figure 13: Fusion Applications Topology for Internal and External Virtual Hosts
In the example shown above, a Fusion Applications client would have access to all composites - A, B,
and C and any service endpoints that they provide. In contrast, external clients are restricted to
accessing only services provided through composites A and B.
Fusion Applications SOA composites that invoke asynchronous services external to the Fusion Apps
domains need to handle the asynchronous callback from that external system to the origin composite.
SOA runtime has a system property that defines the default virtual host to be injected in all generated
URLs, such as the callback URL. For Fusion Applications, this system level property is set by
provisioning to the internal hostname. This works for all intra-Fusion Applications communications,
however, it is important to ensure that any outbound external asynchronous web service invocation
sends the correct External OHS address as its callback address, so that the callback message can be
routed correctly to the originating composite.
To allow this, the SOA runtime supports overriding the generated URL for the asynchronous service
callback through a binding property on the composite service reference. This callbackServerURL
property can only be set during design time and not dynamically through BPEL activities. It should be
set in the composite.xml binding.ws elements to the External OHS URL for all bindings that invoke
external asynchronous web services. This is already done for all out-of-the-box Fusion Applications
composites that invoke external asynchronous web services. For any custom developed composites,
the callback property needs to be set as well as the required routing rules need to be provisioned. The
following shows an example of a composite in a deployed environment with the callback property set.
18
<service name="foo" ui:wsdlLocation="foo.wsdl">

<interface.wsdl
interface="http://xmlns.oracle.com/foo#wsdl.interface(fooProcess)"/>
<binding.ws
port="http://xmlns.oracle.com/foo#wsdl.endpoint(fooprocess_client_ep/fooProcess_pt)"/>
</service>
<component name="bpelProc" version="1.1">

<implementation.bpel src="bpelProc.bpel"/>
</component>
<reference name="foo" ui:wsdlLocation="http://mycompany.com/someExternalService?WSDL">

<interface.wsdl
interface="http://mycompany.com/someExternalService#wsdl.interface(fooInterface)"/>
<binding.ws port="http://mycompany.com/someExternalService#wsdl.endpoint(fooPort)"
location="http://mycompany.com:/someExternalService?WSDL"
soapVersion="1.1">
<wsp:PolicyReference
URI="oracle/wss11_saml_token_with_message_protection_client_policy"
orawsp:category="security"
orawsp:status="enabled"/>
<property name="weblogic.wsee.wsat.transaction.flowOption" type="xs:string"
many="false">
WSDLDriven
</property>
<property name="callbackServerURL" type="xs:string" many="false">
http://prod.mycompany.com/soa-infra/default/myComposite!1.0
</property>
</binding.ws>
</reference>
Set the default value for callbackServerURL to http://your.soa.host.domain:your_soa_port,

which can then be replaced by config plans during deployment.
Caution: Do not change the SOA runtime server URL to the External OHS. This would disable
the ability for composites to make asynchronous web service calls, even internally across applications.
At runtime when SOA performs an asynchronous web service call, the WS-Address portion of the
SOAP header is populated with a pre-built "replyTo" value which will give the remote service the
information needed to perform the proper callback invocation.
For this pattern to work, the custom callback service must also be exposed through the external virtual
host, and routing rules need to be added. This will effectively make all composite services for the
composite to be external, which means security policies should be changed to accommodate that.
To modify the callbackServerURL property using config plans, ensure that it is being set at the
relevant binding sections. Technically speaking, each binding can have a different callback URL,
although this is not a common use case unless the callbacks are routed through a different composite.
For development and QA purposes, the choice of using the same URL for Internal and External OHS
is up to the developers. For production use however, the external URL tokens must be injected, as
shown in the sample provisioning config plan below.
19
<?xml version="1.0" encoding="UTF-8"?>

<SOAConfigPlan xmlns="http://schemas.oracle.com/soa/configplan">
<composite name="OverrideAsyncCallback">
<reference name="AsyncHelloWorld">
<binding type="ws">
<property name="callbackServerURL">
<replace>http://prod.mycompany.com:8080</replace>
</property>
<property name="endpointURI">
<replace>http://prod.mycompany.com:7001/WFClientPatternApp-Project2-
context-root/AppModuleService</replace>
</property>
</binding>
</reference>
</composite>
</SOAConfigPlan>
To modify the properties via Enterprise Manager, follow these steps:

Navigate to the soa-infra server inside the "SOA" folder under the Middleware Farm branch, clicking
SOA Infrastructure Administration System MBean Browser.
Search the name of the Composite Service Reference as it is defined in the composite metadata, for
example, "AsyncHelloWorld".
Browse through results and navigate to the composite's binding MBeans for that service reference.
For asynchronous service references there will be two bindings, one each for callback and request;
which can be determined by expanding the MBean and looking for the parameter value "callback=true".
Figure 14: Access MBean properties in Enterprise Manager
Click the "Operations" tab then the "setStringProperty" link.
20
Figure 15: Access MBean Operations in Enterprise Manager
In the pair of string form elements, set the property name as callbackServerURL, a value valid value
and click "Invoke", as shown below. The settings should take effect immediately.
Figure 16: Example of callbackServerURL setting
21
Accessing Extended Attributes at Runtime
Partner built integration solutions may need to access extended Flexfield data at runtime for outbound
web service calls, without having to depend on it at design time. The recommended pattern to access
the extended attributes at runtime is via their encapsulating XML node elements. This is similar to the
inbound invocations, however the inbound design pattern used XSL extension templates to map
external data to FlexField attributes. For outbound web services, it is difficult to predict every possible
attribute expected by external systems; hence the use of extension templates is not very practical.
The recommended design pattern is to copy all extended attributes from the source Fusion
Applications system and propagate them to a target external system. As shown in the XSL code
snippet below, a node copy of the entire source extended attributes to the target open content node
named USERAREA can be performed. This way, extended attribute details are not needed at design
time, but at runtime, the implementation specific attributes are copied without any code change.
<ns4:USERAREA>
<xsl:copy-of select="/ns3:item/ns3:j_ItemEffCategory"/>
</ns4:USERAREA>
If the target system needs a strongly typed attribute instead of the open content, this can be made
possible by providing an empty customizable scope (a hook) in the BPEL process following the XSL
transformation above. This scope can then be customized with an additional XSL transform activity
that copies the extended attributes from the USERAREA node to the specific XML elements.
Note that the design pattern above requires target system schema documents to contain open/opaque
elements (i.e. xsd:any). While this is the case with some open standards such as the Open Applications
Group (OAG), not all external applications may support it. It also requires a two-pass transformation,
which can impact performance. If a solution needs very high performance or has a restrictive target
schema, an alternative is to customize the transform activity and the XSL with the required FlexField
attributes. It should be noted that this approach is not upgrade safe and future code versions will
overwrite the base XSL requiring customers to do a three way merge to incorporate their
customizations on top of the upgraded code. Therefore, such customizations should be considered as
the last resort.
Using a Service Bus for Service Virtualization and Location Transparency
Web service invocation patterns described above work well with a limited number of external services.
For more flexible integration needs, the use of a service bus such as the Oracle Service Bus (OSB)
is recommended to provide virtualization of the invoked services as well as location transparency.
For example, Fusion CRM applications may need to send order fulfillment requests to an on-premise
order management system. Large customers may in fact have multiple order management systems, for
example one system for each geographic location where the company operates. The CRM system
however should not need to be aware of each back-end system and geography. Instead, it would be
recommended to use a pattern that provides location transparency i.e. be agnostic to the back-end
system. This can be achieved by sending the order fulfillment requests to a single service (e.g. OSB)
that is responsible for doing the transformation and context based routing.
22
Event Notifications using CRM Outbound Messages

Fusion CRM provides an extensibility framework that can send an outbound message payload using an
ADF Service Data Object (SDO) payload to an external URL, which implements a web service using
the WSDL and security contract defined by Fusion Applications. The payload consists of the entire
SDO (including child object SDO if applicable); and in case of record updates, it consists of the
current updated values. This pattern is recommended for CRM object event notifications, as it
provides dedicated user interface for specifying the object change events (e.g. Sales Opportunity
Updated) and the destination URLs.
Figure 17: CRM Extensibility Framework with Outbound Message feature runtime
As shown above, the Fusion CRM Extensibility framework raises an event, which is processed by the
SOA composite service to determine the event action that needs to be taken. The Outbound Message
action sends the event payload (containing the SDO) to an endpoint URL. Customers can configure
the object workflow (e.g. Lead, Opportunity or Account), specify a raise condition on a Create or
Update event point, and specify the action and end-point URL of the third party web service setup.
Outbound messages are queued up for processing, and are monitored via Oracle Enterprise Manager.
With this pattern, an intermediary service will be needed that transforms data and handle callbacks
from any third party web service being invoked. This service can be a custom SOA composite or a web
service implemented and deployed using the WSDL and XSD provided for the objects (shown below).
//OutboundMessageService.wsdl
<wsdl:definitions
name="OutboundMessageService"
targetNamespace="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/"
xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:types="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
>
<wsdl:import namespace="http://xmlns.oracle.com/adf/svc/errors/"
location="ServiceException.wsdl"/>
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import
namespace="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
23
schemaLocation="OutboundMessageService.xsd"/>
</schema>
</wsdl:types>
<wsdl:message name="OutboundMessageService_processOutboundMessage">
<wsdl:part name="parameters" element="types:processOutboundMessage"/>
</wsdl:message>
<wsdl:message name="OutboundMessageService_processOutboundMessageResponse">
<wsdl:part name="parameters" element="types:processOutboundMessageResponse"/>
</wsdl:message>
<wsdl:portType name="OutboundMessageService">
<wsdl:documentation/>
<wsdl:operation name="processOutboundMessage">
<wsdl:input message="tns:OutboundMessageService_processOutboundMessage"/>
<wsdl:output
message="tns:OutboundMessageService_processOutboundMessageResponse"/>
<wsdl:fault name="ServiceException" message="errors:ServiceException"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="OutboundMessageServiceSoapHttp"
type="tns:OutboundMessageService">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="processOutboundMessage">
<soap:operation
soapAction="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/processOutbo
undMessage"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="ServiceException">
<soap:fault name="ServiceException" use="literal" encodingStyle=""/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="OutboundMessageService">
<wsdl:port name="OutboundMessageServiceSoapHttpPort"
binding="tns:OutboundMessageServiceSoapHttp">
<soap:address
location="http://erp.mycompany.com:7101/OMInterface/OutboundMessageService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
// Sample: OutboundMessageService.xsd
<schema elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
xmlns:ns0="http://xmlns.oracle.com/adf/svc/errors/"
xmlns:ns1="$OBJECT_TARGET_NAMESPACE$"
xmlns:ns2="http://xmlns.oracle.com/adf/svc/types/"
xmlns:tns="http://xmlns.oracle.com/apps/crmCommon/content/outboundMessage/types/"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://xmlns.oracle.com/adf/svc/types/"
schemaLocation="BC4JService.xsd"/>
<import namespace="$OBJECT_TARGET_NAMESPACE$" schemaLocation="$OBJECT_NAME$.xsd"/>
<import namespace="http://xmlns.oracle.com/adf/svc/errors/"
schemaLocation="ServiceException.xsd"/>
<element name="processOutboundMessage">
<complexType>
<sequence>
<element name="object" type="ns1:$OBJECT_NAME$"/>
24
</sequence>
</complexType>
</element>
<element name="processOutboundMessageResponse">
<complexType>
<sequence/>
</complexType>
</element>
</schema>
Replace the parameters in the XSD schema above with the object name from the ADF service schema
files. For standard out of the box (OOTB) objects, search Asset Type=FusionApps: ADF Service in
OER by object name, navigate to the service and download the object schema. For custom objects,
search for the generic Web service for all custom objects in the corresponding application, for
example, Sales Custom Business Object.
Since there is one WSDL that includes the schema from the above XSD, multiple outbound messages
can be included by adding all the interested objects in the schema using different namespaces.
The object workflow outbound messages use an authentication-only client side security policy
oracle/wss10_saml_token_client_policy that includes SAML tokens in outbound SOAP request messages.
The external service should use the service policy oracle/wss10_saml_token_service_policy, which can be
enforced on any SOAP-based endpoint. For more information about Fusion web service configuration
and security, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Invoking Custom CRM Business Processes for Integration

The Fusion CRM extensibility framework described earlier also enables customers to listen to business
events from CRM and invoke custom business processes, which can be used to integrate approvals and
other human workflow activities. The Application Composer integrates with the BPM Composer to
allow creating or updating projects based on BPM Composer processes.
Figure 18: Invoking BPM Composer from Application Composer
25
Once a BPM project is deployed, it is associated to the object for which approval is being configured in
the Object Workflows UI. The mapping of BPM Process parameters is done in this UI, and is used
when the process gets initiated upon the object condition being met, as shown below.
Figure 19: Mapping of Business Process parameters and Conditions
26
SCM Distributed Order Orchestration: External Interface Layer

Fusion SCM DOO has an External Interface Layer (EIL) functionality that notifies downstream
systems of fulfillment order status updates using web service invocations. EIL specifies a WSDL
contract which is implemented by customers and the external service URL is registered back with the
Fusion SCM DOO application. At runtime, the external Service URL is dynamically invoked using
BPEL dynamic invocation feature, based on the business rules (using Oracle Business Rules or OBR).
The EIL framework uses OWSM client side security policies as discussed earlier. For more information
about Fusion web service configuration and security, see Oracle Fusion Middleware Security and
Administrator's Guide for Web Services.
Fusion DOO side of integration natively uses Oracle Application Integration Architecture (AIA)
canonical message formats and services, essentially eliminating the need for an AIA connector on the
Fusion side of things (inbound and outbound). It provides web services & data staging tables and uses
standard set of Oracle tools to create integrations.
Bulk Import: Importing Data in Fusion Apps
Importing Data in On-Premise Scenarios
The recommended pattern for importing data in an on-premise deployment is to upload data to the
Fusion Applications Interface tables, then invoking pre-seeded background processing jobs that load
the data into the Fusion base tables. The only exception to this would be if any specific Fusion
application provides native capability with pre/post processing capabilities needed for its operation,
such as a Customer import that performs de-duplication. For the interface table approach, the table
descriptions and the processing job descriptions can be found in OER as described in earlier sections.
Uploading data into the Fusion Applications Interface tables can be done in a variety of ways. The
primary recommended approach for importing data to interface tables is using Oracle Data Integrator
(ODI), which can import data from external databases or XML files. The jobs can also be monitored
using Fusion Applications Control. The diagram below shows this pattern.
Figure 20: Batch Import Integration Pattern
Note: Use of SQL for loading data into interface tables is a legitimate approach, however it requires
manual mapping of file data to the columns, error handling etc, and is not a recommended approach.
27
Batch Import CRM Applications
Fusion CRM uses a File-based Data Import tool that imports data from flat files from local or network
locations into interface tables, and then invokes background ODI bulk import programs to move that
data to the Fusion Applications base tables. It can also transparently break large files into smaller
chunks for transmission across the internet or through firewalls. Customizations done via Application
Composer automatically modify the ODI processes and maps without user interaction, and are visible
to the import tool. The import tool supports importing child objects. The parent and child information
must be contained in the same import file, and the mapping of source values to target columns is done
as part of the job definition process. The following diagram show cases the tools approach.
Figure 21: CRM Batch Import Implementation: File-based Data Import tool
Fusion CRM also provides an application specific Data Import facility for on-premise scenarios, which
is similar to the File-based Data Import, but focused on Customer, Partner and Employee Resource
objects. Being object focused, it provides pre-processing data cleansing and de-duplication capabilities,
allowing users to perform what if analysis and data clean up in the interface tables before loading to
the base tables. Note that the Data Import facility only works against already existing data in customer
interface tables, requiring an ODI job to first import the file data into the interface tables.
To import Products data into Fusion CRM, a separate program called Create/Manage Items is used to
load product information using ADFdi (ADF Desktop Integration) and Microsoft Excel templates.
For more details, refer to Customer Data Management Implementation Guide and Fusion CRM
Integration Patterns Cookbook.
Batch Import HCM Applications
Fusion HCM (Talent Management) incorporates a batch loading mechanism using a variant of the
ODI loading pattern to load data. Instead of interface tables, the primary input interface is data files
28
that are FTPed securely to a server directory, compared against Fusion Applications and staged in
interface tables using ODI. A batch processing job updates the Fusion base tables (with date tracking)
using ADF services, triggering all the implemented validations on the ADF entity object level and
ensuring that data is consistent, appropriately defaulted and processed. Any errors are logged against
the interface table entries. The solution supports initial data load and re-loads after error corrections.
Bulk Export: Exporting Data from Fusion Apps
Batch Export CRM Applications
Fusion CRM Applications has a Bulk Export tool, which extracts data from CRM objects and writes to
.csv files. It leverages reusable mapping files to define filters that specify object columns and rows to
extract, without using intermediary interface tables. It has execution and scheduling capability similar to
the File-based Data Import tool, supports export of parent and child objects, and also supports object
customizations. It provides a web service API for job invocation which contains methods for invoking
processes, finding the results of previous process execution runs, and finding the exported files. API
use is recommended when recurring incremental extracts are required, since it provides additional
input parameters for process execution that specify start/end times of each increment. For additional
information on the Bulk Export service API and associated methods, refer to the Oracle Enterprise
Repository -- search for asset Type = FusionApps: ADF Service and Search String = Bulk Export.
The diagram below shows this export capability in Fusion Applications.
Figure 22: CRM Batch Export Implementation: Bulk Export tool
For more information, refer to the Fusion CRM Integration Patterns Cookbook.
29
Bulk Export HCM Applications
Fusion HCM Extracts is a reporting and interface tool used for high volume complex reporting,
extraction and archiving. It uses the concept of an extract block/level to define the data set to be
extracted from each logical entity; and block criteria to define filter conditions on each logical entity for
data extraction. Extract block links form a hierarchy of blocks that pass the context information
during processing. The extract definition is specified using Record Layout and Data Elements with
parameters that are used in criteria conditions for extracting the required data set. The extract is multi-
threaded, handles error/warning logs and has re-processing capabilities. Data extracted from a run is
sent to a Write process (based on BI Publisher Bursting Engine, Delivery Manager), which delivers the
extract results in a flat file, or in the required delivery method (mail, fax, ftp, etc) and required format
(txt, html, pdf, etc). BI publisher is used for generating data in different formats, as shown below.
Figure 23: HCM Batch Export Implementation
The delivery options available to process the extracted data (e.g. into flat files) is shown below.
Figure 24: HCM Extract Delivery Options
For data export of HR Benefits information, use the Benefits Extract in HCM, which can be invoked
from the Data Exchange landing page. The extraction details can be specified on a per-provider basis,
with the option of exporting the data in a generic System Extract format or a standard, canonical
HR-XML format for use with any service that can publish the data to third party systems.
30
UI Level Integrations
Data Aggregation using ADF Service Callouts
CRM implementations typically have a need to provide an aggregated view of a customer, for which
the data may not be residing in CRM database. For example, a call center agent using a CRM
application may need to know everything about a customer when they are on the phone e.g. orders
placed by the customer in the past 30 days, trouble tickets submitted in the past 14 days, products
installed at the customer premises, loyalty analytics etc.
Since all this information may reside in various back end systems, the CRM application will need to
collect all the information from various sources (using many web service call-outs) and render them on
the customer profile user interface rather than expecting the agent to go to each one of the back office
systems and retrieve the information (swivel chair integration).
The web service call-outs can be done at the ADF Service Application Module layer, with the resultant
data retrieved and assigned to the ADF View Object data controls so that they can be rendered as
needed on the UI. Of course, this requires Java level extensions which are not flexible to change. A
better approach for extensibility is a pattern wherein the ADF layer is integrated with a fixed
integration service, for example using Oracle Service Bus (OSB). In this pattern, the interface between
the CRM ADF application and the integration service is fixed (but yet extensible using a loosely typed
interface) and all the web service call-outs are done via the OSB integration layer.
UI Mash-up with Fusion Applications
Apart from server side integration patterns explained above, there are various use cases wherein the
integration of third party systems needs to occur at the user interface level. A common need is to
integrate information from various third party or legacy applications in the Fusion Applications UI, so
that users can avoid swivel chair integration. Some examples are:
Getting a 360 degree view of the customer by integrating content from an enterprises third party and
legacy systems to retrieve a customers invoices, orders, order fulfillment status, credit rating etc and
display them in Fusion Applications.
Leveraging a specialized order configuration application (e.g. Oracle Configurator) as part of order
capture process in Fusion Applications.
Show transaction details from existing legacy systems e.g. show invoice details from a legacy system.
Retrieve information from an industry specific application e.g. get billing information from Oracle
Billing and Revenue Management and show that alongside customer information in Fusion
Applications.
Pull in value-added data over the cloud e.g. LinkedIn updates for HR candidates, Twitter and
Facebook newsfeed for Contacts, Google Map for addresses etc.
There are various approaches that can be employed to show this information at the application level.
The information pulled in may be embedded in the Fusion Applications pages, be invoked in a new
31
popup window on a button click or link, or be associated with a custom sub-tab on the main object
page. In all of these cases, the pattern is to use the Fusion Applications customization frameworks e.g.
Application Composer, Page Composer etc. to add buttons/links that can invoke/embed the external
information by dynamically constructing the remote URL.
Refer to the Application Composer Guide or the Fusion CRM Integration Patterns white paper for
more details on these UI patterns and how to implement them.
Conclusion
This was an overview of integrating with Fusion Applications using best practice design patterns with
Oracle SOA Suite. For a more comprehensive guide, please review the Developers Guide for Oracle
Fusion Applications and Oracle Fusion Middleware SOA Suite.
Glossary
ITEM MEANING
Metadata Services (MDS) A central repository of XML artifacts, accessed at runtime.
File-based Import Tool Oracle CRM tool that enables bulk data import data to Fusion CRM schema. The File-
based Import Tool uses ODI technology to load data from its interface tables to Fusion base
tables.
Also see: Oracle Data Integrator (ODI)
Oracle Data Integrator Oracle tool that enables bulk data import data.
(ODI) Also see: File-based Import Tool
Service Data Object Data structure for the web services that uses standards based representation of entity data.
(SDO)
Non-Idempotent Service A service that produces a different functional outcome when re-executed with the same
inputs. If the service produces the exact same outcome regardless of the number of
executions using the same inputs, it is called an idempotent service.
Application Composer Oracle CRM-centric tool that enables application tailoring, extensibility.
Oracle Composer Also known as Page Composer.
Oracle capability that enables Fusion CRM Dashboard tailoring.
Groovy Scripting language leveraged by Application Composer to enhance functional flows.
32
Integrating with Fusion Applications Overview Copyright 2011, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
of Design Patterns contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
February 2012 warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
Author: Rajesh Raheja fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
Contributing Authors: Fusion Middleware SOA formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
Suite and Fusion Applications Teams means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle Corporation
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
World Headquarters
500 Oracle Parkway
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
Redwood Shores, CA 94065
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
U.S.A.
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark licensed through X/Open
Worldwide Inquiries: Company, Ltd. 0611
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

Fusion Apps Integration Patterns WP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Fusion Apps Integration Patterns WP

Transféré par

Droits d'auteur :

Formats disponibles

An Oracle White Paper

Integrating with Fusion Applications

Executive Overview ........................................................................... 1

Integration Design Patterns

Figure 1: Fusion Macro Patterns using SOA

Inbound: Calling Fusion Applications Web Services

Invoking ADF Services

Figure 2: ADF Service Call

Figure 3: Asynchronous Web Service Call

The following describes the flow shown in the previous figure:

Invoking Composite Web Services

Composite web services can be invoked in a synchronous request-reply, asynchronous request-reply as

Figure 4: Recommended pattern for invoking composites from ADF

Primary Key Management

Figure 5: Syncing ADF MDS with SOA MDS

Accessing Extended Attributes at Runtime

Figure 6: Fusion Applications SOA Security Points

$ keytool -list -keystore ./oracle-keystore.jks

WSBindingProvider wsbp = (WSBindingProvider)opportunityService;

//Specify the keystore details

//Password to access Keystore file

//Public key from Server for signing and encrypting

//Username and password to access the Fusion CRM instance

Handling Faults in Composite Service Instances

Figure 7: Retry of Non-Idempotent Services on Recovery

Best Practices for Fusion Applications Web Services

Outbound: Calling External Applications

Raising Custom Business Events

Invocations from New or Customized Processes

Figure 8: Add Web Service to Composite in Jdeveloper

Figure 9: Add Partner Link in BPEL

Figure 10: Add Routing Rule in Mediator

Figure 11: Use Technology or Application Adapters

Invocations from pre-built composites using Dynamic Partner Links

External Service Invocation without Dynamic Partner Links

Security for External Web Service Invocation

Receiving Asynchronous Callbacks from External Systems

<service name="foo" ui:wsdlLocation="foo.wsdl">

<component name="bpelProc" version="1.1">

<reference name="foo" ui:wsdlLocation="http://mycompany.com/someExternalService?WSDL">

Set the default value for callbackServerURL to http://your.soa.host.domain:your_soa_port,

<?xml version="1.0" encoding="UTF-8"?>

To modify the properties via Enterprise Manager, follow these steps:

Figure 14: Access MBean properties in Enterprise Manager

Click the "Operations" tab then the "setStringProperty" link.

Figure 15: Access MBean Operations in Enterprise Manager

Figure 16: Example of callbackServerURL setting

Accessing Extended Attributes at Runtime

Using a Service Bus for Service Virtualization and Location Transparency

Event Notifications using CRM Outbound Messages

Invoking Custom CRM Business Processes for Integration

Figure 18: Invoking BPM Composer from Application Composer

Figure 19: Mapping of Business Process parameters and Conditions

SCM Distributed Order Orchestration: External Interface Layer

Bulk Import: Importing Data in Fusion Apps

Importing Data in On-Premise Scenarios

Figure 20: Batch Import Integration Pattern

Batch Import CRM Applications

Batch Import HCM Applications

Bulk Export: Exporting Data from Fusion Apps

Batch Export CRM Applications

Figure 22: CRM Batch Export Implementation: Bulk Export tool

Bulk Export HCM Applications

Figure 23: HCM Batch Export Implementation