Connectors consist of two components: the connector framework and the application-specific component. The connector framework, whose code is common to all connectors, acts as an intermediary between the integration broker and the application-specific component. The application-specific component contains code tailored to a particular technology (in this case, JD Edwards OneWorld) or application. The connector framework provides the following services between the integration broker and the application-specific component:
This document contains information about both the connector framework and the application-specific component. It refers to both of these components as the connector.
All WebSphere business integration adapters operate with an integration broker. The connector for JD Edwards OneWorld operates with WebSphere InterChange Server, WebSphere MQ Integrator Broker, or WebSphere Application Server. For more information, see the installation and implementation documentation of your broker.
Figure 1. Connector architecture
OneWorld business functions perform specific tasks, such as journal entry transactions, calculating deprecation, and sales order transactions. There are two types of business functions. Regular business functions perform simple tasks, such as tax calculation or account number validation. Master business functions perform tasks that are more complex, and can call several regular business functions to perform those tasks.
The interoperability framework includes business function wrappers that provide a single point of access to major and minor business functions. It also includes master business function wrappers.
When there are no business functions available to call a particular business object, you can use XML List. The following diagram illustrates the flow of an XML call.
I
When an XML call occurs, the following steps happen:
The following diagram illustrates the process flow for ThinNet used in XMLCallObject.
The following diagram illustrates the adapter architecture.
Figure 4. Architectural diagram
OneWorld supports several APIs for communication with third-party applications such as Java, COM, Oracle Database Applications, XML, and Table Conversion.
The adapter uses the Java APIs for invoking business functions in OneWorld. The business objects map to business function classes or objects.
A summary of the implementation is as follows:
When the connector framework receives a request from the broker, it calls the doVerbFor() method of the business-object-handler class associated with the business object definition of the request business object. The role of the doVerbFor() method is to determine the verb processing to perform, based on the active verb of the request business object. It obtains information from the request business object to build and send requests for operations to the application.
When the connector framework passes the request business object to doVerbFor(), if the business object maps to an interface object, the business object handler reads the verb ASI and translates it into a series of callable functions. You can give these functions specific semantic meaning through the Object Discovery Agent (ODA) running in Business Object Designer. For details about using the ODA to assign a method call sequence to a verb, see Creating and modifying business objects. The order in which the calls are made is critical to the successful processing of the object.
In the case of an interface business object with a blank verb ASI, the business object handler searches for a business function attribute with populated parameters and calls that business function. Only one method can be populated; otherwise, if multiple methods are populated but the verb ASI is blank, the connector logs an error and returns a FAIL code. For details about error processing, see Error handling.
If the business object maps to a business function object, the business object handler invokes the specific business function with the data specified in the business object.
If retrieval business functions are not available for specific business objects, you can use the XML List API for retrieval functionality.
The connector does not support any specific verbs for the interface business objects, but using the ODA, the user can configure verbs for a business object. The standard verbs used by WebSphere Business Integration are Create, Retrieve, Update, and Delete.
For business function business objects, the ODA generates a default verb, Execute. The verb ASI is not required for these business objects.
To support special access permissions for a business object, a meta business object is defined with the name ACCESS_LEVEL. The ACCESS_LEVEL business object has two attributes, Username and Password, both of type String. A OneWorld business object that has special access rules and cannot be accessed through the Username specified in the connector configuration file, would have this business object (ACCESS_LEVEL) as a child business object with single cardinality. You must add this child business object only to the top-level business object in a doVerbFor call. All the child business objects for this top-level business object must be accessible through the Username specified in the ACCESS_LEVEL child business object.
The business object handler checks to see if the top-level business object has a child business object of type ACCESS_LEVEL. If yes, and the value for the Username attribute in that business object is different from what is being used by the adapter, then it opens a new connection for processing this business object using the value for attributes Username and Password of the child business object. The connection closes after the processing of the business object is complete.
If the top-level business object does not have a child business object of type ACCESS_LEVEL, or the value of the Username attribute is the same as the Username specified in the adapter properties, the business object handler fetches a connection object from the pool.
If there is no available connection object and the maximum limit of the pool size is not reached, the business object handler creates a new connection object in the pool. If there is no available connection object and the maximum limit of the pool size is reached, then it waits for a connection object become available.
The adapter supports top-level business objects as the ones that map to OneWorld interface classes or XML List business objects. It also supports business objects that map to business functions as top-level business objects. The adapter handles the business object based upon the type and structure of the business object. Instead of relying completely on the business objects generated by the ODA, you can create your own hierarchy using the business objects that map to business functions to give a logical representation. For example, the business functions for creating an Order and creating an Order Item can be modeled as a hierarchy. The business objects that map to business functions that create OrderItems would become child business objects of the business object that maps to create the Order business object.
The adapter executes top-level business objects that map to business functions. If the business object does not have any child business objects, the adapter executes the business function that corresponds to the business object. If the hierarchy of such business objects is an input to the business object handler, then, the adapter executes all the business functions in one transaction. In this case, the verb ASI is blank and the flow of the business functions are determined by the order of attributes in the top-level business object. For example, if the top-level business object maps to B110031 and has children B110032 and B110033, then the order of the execution is B110031, B110032, B110033.
If the type attribute of the business object is XMLList, then the business object handler prepares an XML document with values and format defined by the business object. The adapter sends the XML document to OneWorld, using the XMLRequest object. The adapter receives the response as an XML response document and the handler uses the response data from the XML response document to populate the business object.
In some cases, a single simple attribute or an object may need to be used multiple times in a call sequence. You can use Attribute ASI to link two attributes. If an attribute is marked as a foreign key, it must have an attribute ASI, use_attribute_value= tag, the value of which must correspond to BusinessObject.AttributeName. Use this link only if the source business object is of single cardinality. If it is configured with a source business object with multiple cardinality, then the adapter picks up the first business object from the list and maps the value from that business object.
Event notification requires the installation of the event package, BIA_EVENT, shipped with the adapter and the creation of event and archive tables in the JDE database.
For information about how to install and configure the BIA_EVENT event package, refer to Installing and configuring IBM event store.
The creation, update, or deletion of any record in the JD Edwards OneWorld application can be treated as an event. You can use table triggers, supported by OneWorld, to populate the event table. You can also use any other JD Edwards recommended method to generate events into the event table. During a call to pollForEvents, these records are obtained and processed. The Event table stores information about the event, as described in Table 6.
Retrieval of objects for event processing is based on both key and non-key attributes. It is mandatory that the business object support the Execute verb if the business object represents a JD Edwards business function and that is supports the Retrieve verb if the business objects represents an interface.
The connector polls the IBM Event table (F5501005) at a regular interval, retrieves the events, and processes the events first by priority and then sequentially. When the connector has processed an event, the event's status is updated appropriately.
The setting of the ArchiveProcessed property determines whether the connector archives an event into the IBM Archive table (F5501006) after updating its status. For more information on the ArchiveProcessed property, see Connector-specific properties. Table 3 illustrates the archiving behavior depending on the setting of the ArchiveProcessed property.