Oracle® Fusion Applications Developer's Guide 11g Release 6 (11.1.6) Part Number E15524-11 |
|
|
PDF · Mobi · ePub |
This chapter describes what to do when you need to work with data from a remote Oracle ADF Fusion Business Service in the format of an ADF Business Components component, such as rendering the data in a UI table, or creating a view link to it.
When to implement: When you need to work with data from a remote Oracle ADF Fusion Business Service in the format of an ADF Business Components component, such as rendering the data in a UI table, or creating a view link to it.
Design Pattern Summary: Create service-based entity objects and view objects and use these entity objects and view objects as normal ADF Business Components either in your business logic or for rendering on UI pages to simplify the task.
Involved components:
ADF Business Components service that accesses data from a different pillar.
Entity object based on the ADF Business Components service, and view object on top of the entity object.
When you want to work with data from a remote ADF Business Components service, you can create service-based entity objects and view objects to simplify the task. A service-based entity object is an entity object that encapsulates the details of accessing and modifying a row of data from a remote ADF Business Components service. The service-based entity object then can be used in the same way as a normal database-table-based entity object.
If the data that you need to work with is always local to you, that is, available in the same database, then a table-based entity object should be used instead. The service-based entity object or view object will have additional performance overhead since each has an extra service layer.
Instead of wrapping with a service-based entity object or view object, you always can invoke the ADF Business Components service directly. For more information, see Chapter 42, "Synchronously Invoking an ADF Business Components Service from an Oracle ADF Application." Since UI components cannot be bound to Service Data Objects (SDOs) directly and an ADF Business Components service only accesses SDOs, using service-based entity objects and view objects is a simpler approach, especially if you just need to invoke a method as part of your business logic and you do not need to bind the input/output of the method to UI components.
Instead of creating an entity object on top of a database schema, you create it based on a WSDL.
To create service-based entity objects and view objects:
Ensure that the WSDL file of the targeted ADF Business Components service is available, either from your file system or from a URL.
Create a new entity object using the Create Entity Object wizard.
Note:
Instead of using a database schema object for the entity's data source, select Service Interface. For more information see the section "Accessing Remote Data Over the Service-Enabled Application Module" in the chapter "Integrating Service-Enabled Application Modules" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Create a view object on top of the entity object that you created in the previous step. This step is the same as creating a normal entity object-based view object. For more information, see the chapter "Defining SQL Queries Using View Objects" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Register the targeted service in your connections.xml
file (found in Application Resources > Descriptors > ADF META-INF). This entry is needed during runtime to invoke the service. Note that this also requires that the targeted service be hosted and running, since the registration requires the URL of where the service is deployed. Example 40-1 shows sample code used in the connections.xml
file.
Example 40-1 Sample connections.xml Code
<Reference name="{http://xmlns.oracle.com/apps/adfsvc/deptempService/}DeptEmpService" className="oracle.jbo.client.svc.Service" xmlns=""> <Factory className="oracle.jbo.client.svc.ServiceFactory"/> <RefAddresses> <StringRefAddr addrType="serviceInterfaceName"> <Contents>oracle.apps.adfsvc.deptempService.DeptEmpService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceEndpointProvider"> <Contents>ADFBC</Contents> </StringRefAddr> <StringRefAddr addrType="jndiName"> <Contents>DeptEmpServiceBean#oracle.apps.adfsvc.deptempService.DeptEmpService</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaName"> <Contents>DeptEmpService.xsd</Contents> </StringRefAddr> <StringRefAddr addrType="serviceSchemaLocation"> <Contents>oracle/apps/adfsvc/deptempService/</Contents> </StringRefAddr> <StringRefAddr addrType="jndiFactoryInitial"> <Contents>weblogic.jndi.WLInitialContextFactory</Contents> </StringRefAddr> <StringRefAddr addrType="jndiProviderURL"> <Contents>t3://localhost:7101</Contents> </StringRefAddr> </RefAddresses> </Reference>
Get the service interface common.jar
file from the service provider, and add the file to your library. This is also required during runtime. The common.jar file is generated when the service provider uses an ADF Business Component Service Interface deployment profile to deploy.
For more information about securing the use case, see Chapter 51, "Securing Web Services Use Cases."
To properly verify this design pattern, test your service-based view object in an application module tester, then deploy and test the application that uses the service-based entity object and view object.
To verify this design pattern:
Test your Oracle ADF application using the various testing and debugging methods described in the chapter "Testing and Debugging ADF Components" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Note that the underlying data source for service-based entity objects and view objects is an ADF Business Components service, which is stateless and in a different transaction. When you commit your transaction of your local application module, a service call will be made if there is any change in the service-based entity object that is not part of your local transaction. If the service invocation fails, then the local transaction also will fail. However, if the service invocation succeeds and then later your local transaction fails, it is your error handling code that must perform a compensating transaction against the remote service to "undo" the previous change made.
Known limitations are the following:
A service-based entity object cannot be referenced as an secondary entity usage in a view object.
A service-based view object cannot have secondary entity usages.
These limitations mean that you cannot create a flattened join of multiple entities if one of them is a service-based entity object. The workaround is to use a view link to traverse from one view object to another.