O 9IAS: THE SEVEN BASIC CONCEPTS OF INTEGRATION · can satisfy this demand with a single product...

Oracle9iAS: The Seven Basic Concepts of Integration

Paper 32786

OORRAACCLLEE99IIAASS:: TTHHEE SSEEVVEENN BBAASSIICC CCOONNCCEEPPTTSS OOFF IINNTTEEGGRRAATTIIOONN

Christopher Bussler and Bart van der Hoeven, Oracle Corporation

EXECUTIVE SUMMARY The ability to integrate internal and external partner applications in a reliable, secure and intelligent manner holds the promise of faster and more flexible interactions with customers, suppliers and partners. Accepting the challenge requires a centralized enterprise view over business events, business processes and integrated end points. Only Oracle can satisfy this demand with a single product approach for event management, process management and end point management. Oracle9iAS Integration 9.0.4 is a single enterprise-level product that enables the integration of applications within the enterprise and between companies using B2B standards. Oracle9iAS Integration 9.0.4 provides a single relational normalized schema to design and run integrations, allowing retrieving information about the integrations in any way possible. Maintainability, life cycle management and versioning are just a few of the advantages of the Oracle product approach to solve the integration problem. Reuse of event and process definitions provides consistency, less testing effort, no duplication and execution stability. A single tool is provided to model events, processes and end points, maintain application and trading partner profile information, deploy from the design-time environment to the run-time environment, administer and monitor the ongoing integrations. Using the highly scaleable and reliable Oralce9i Database as the foundation and the Oracle9i Application Server, the Oracle9iAS Integration 9.0.4 product approach is the answer for enterprises challenged by reliable management of their complex IT infrastructure and their interactions with customers, suppliers and partners.

A SINGLE PRODUCT FOR INTEGRATION Consider the following typical multi-point integration scenario:

• A sales manager wants to close a deal with a prospect. Before the deal can be closed a credit approval must be performed. To request the credit approval the sales manager enters the prospect information into an Oracle9i Database called LeadsDB.

• The creation of the new record in the Oracle9i Database must cause the invocation of a web service from a credit company using the Internet. A credit approval request (CAR) is sent to the credit company. The invoked web service returns the result as a credit approval acknowledgment (CAA).

• The results of the credit approval must be sent to the sales manager by e-mail. Additionally, if the credit approval was successful a new customer record must automatically be created in another Oracle9i Database called CustomerDB that has a completely different schema from the LeadsDB database.

This not uncommon scenario poses the following important questions related to selecting an integration product:

• How long does it take to automate this scenario in your organization? Days or weeks or months? • How many products are required to model, deploy and monitor the solution? One or several? • How do you find out what the status of the overall process is? Are there predefined reports or do you have to

code your reports yourself learning yet another programming language? • How much coding do you have to do? Do you code nothing or is it a full-blown engineering project? Oracle believes that you should only need one product, one Meta data repository, one architecture, one tool, one set of concepts to solve this scenario. Oracle believes that you should be able to model and maintain the described scenario without having to write any code. Oracle believes that you should be able to work on business problems without having to worry about integrating different products and technologies yourself first. This requires a new approach to the integration technology infrastructure. It requires a single integration platform that


Paper 32786

addresses all facets of both A2A and B2B integration to be successful in today’s integration market including web services. There is no longer time to be concerned with different technologies and products that constitute many of today’s integration solutions. The vision of Oracle9iAS Integration 9.0.4 is to allow you to focus on solving the business problem and push the technical details of how to do the integration into the background.

TYPES OF INTEGRATION Integration solutions may be broadly classified into 4 types

• Data integration • Function integration • Process integration • Event driven business process integration

DATA INTEGRATION

Data integration solutions address the need for providing a simple, integrated view of data from disparate systems and infrastructures. The guiding principle behind data integration is that the key asset of the enterprise is its data. Data integration may be further classified into

• Common schema integration – this type of integration is used when there is a common schema that needs to be integrated. For example, the integration of a payroll database implemented in an Oracle database and a legacy database. This is achieved by database replication functionality.

• Global schema integration – this type of integration is used when there are multiple databases with different schemas and there is a need to present one global view of the data across the databases to the user. This is usually achieved by distributed heterogeneous database integration functionality.

• Homogeneous data integration – this approach is taken when data of two applications or disparate systems needs to be integrated. This is usually achieved by using message brokers or persistent, transactional and reliable queues. Message brokers add transformation, routing and rules-based filtering capabilities to the integration functionality compared to queues.

• Heterogeneous data integration – this approach is taken by products that provide ETL (Extraction - Transformation - Load) capabilities. Data is extracted from one or more source systems, transformed and delivered (or loaded) into one or more target systems. This process might be asynchronous with a staging facility.

Data integration only addresses the need to have a common understanding of the data of an enterprise. In most cases, the data integration results in specific integration logic between applications captured in each application. If another application needs to be integrated into an existing solution, the data passed between applications needs to be changed since, most likely, the new application’s view of the data is slightly or significantly different from the existing semantics of the data.

FUNCTION INTEGRATION

Function integration is also sometimes referred to as application logic integration. In this case, the solution integrates application logic and data between two or more applications. Function integration leverages interfaces exposed by custom or packaged applications. These interfaces (e. g. SAP’s Business API (BAPI)) are used to integrate applications allowing them to integrate business logic and data. Function integration allows for integration of loosely coupled systems using standards based technology like J2EE, JDBC, or EJBs. It allows for implementation of transactional semantics in the integration solution. Function integration requires IT to understand the semantics and the data format of applications that are integrated. While function integration allows for tighter integration of applications that is at the same time also the primary drawback, since it makes the integration solution more complex as other applications are integrated over time.

PROCESS INTEGRATION

The term ‘workflow’ is commonly used to describe this type of integration. Workflow solutions allow users to


Paper 32786

automate business operations, tasks and transactions of business processes within the enterprise. Defining all the business operations pertaining to business processes in an organization helps IT understand the semantics of the integration independent of the endpoints of integration. This greatly increases the ability of the organization to provide solutions to integration needs in the future. Process integration is agnostic to data format or semantics of end points of integration. This makes the integration solution more flexible to enhancements in data format and semantics of data passed between the endpoints. Workflow integrations require point-to-point integration between enterprise applications and the workflow solution. Developers usually hard-code process semantics between individual applications. Limitation of this type of integration is the company’s ability to extend the solution after it has been deployed.

EVENT DRIVEN BUSINESS PROCESS INTEGRATION

Event driven business process integration addresses some of the drawbacks of the previously introduced types of integration. This solution provides integration of business processes based on the data (format and semantics) associated with the business process. By allowing the user to define business processes and business events between applications and trading partners, this approach makes the integration independent of the end point semantics in terms of both data and process, which, in turn, provides IT organizations with the ability to integrate existing applications and trading partners while providing the flexibility to extend the same in the future as more applications, trading partners, and B2B protocols become available for integration. Oracle9iAS Integration 9.0.4 takes this approach to solving integration needs. Oracle9iAS Integration 9.0.4 provides a single integration platform that addresses all facets of A2A and B2B integration with the added focus on solving the business problem and pushing the details of technologies into the background.

ORACLE9IAS INTEGRATION 9.0.4 APPROACH The integration problem can be defined as the challenge to integrate

• All your events (like credit approval requests, purchase orders, shipping requests) • All your processes (like purchase processes, approval processes, supply chain replenishment processes) • All your parties (like back end application systems and trading partners)

META MODEL

Oracle9iAS Integration 9.0.4 provides a predefined set of integration concepts that are the basis for the data model of the underlying relational normalized database schema. Example of integration concepts are business event, translation, transformation, correlation, business process and application roles. In a programming approach to integration there is neither a set of integration concepts nor a well-defined, single normalized database schema

DECLARATIVE LANGUAGE

Because the set of integration concepts is pre-defined the integration modeler has a set of modeling constructs available to him to model integration. Since the database schema is designed to capture the various models the integration modeler has a declarative language available to him. Like SQL, you define what needs to be done, not how. This is again in contrast to programming approaches to integration that require the integration modeler (really the integration programmer) to write many lines of code in order to build the integration solution.

INTERPRETED

The declarative approach to defining integration allows for the interpretation of integration at execution time. Instead of generating code and requiring the maintenance of the generated code an interpreter can access the normalized database schema in order to execute the integration. The interpretation approach is beneficial since this allows managing the system resources independent of the complexity of the integration models and independent of their number. Furthermore, interpretation is advantageous for dynamic modification and reuse of integration models.


Paper 32786

APPROACH ADVANTAGES

• Single, integrated product that enables seamless A2A and B2B integration. It is easy to use, has a limited set of powerful integration concepts and does not require the customer to worry about integrating technology components in order to make the A2A or B2B happen.

• Modeled, not programmed. A modeled approach makes the integration modeler more productive since he has to only specify what has to be integrated, not how.

• One user interface tool to learn. Oracle9iAS Integration 9.0.4 provides one consistent integration tool set that reduces training effort, provides a uniform and consistent user experience for all integration relevant design activities. Furthermore, deployment, analysis and administration are provided in the same toolset.

• Single relational normalized schema. A single schema eases the back up of the complete integration solution, allows to build custom reports with standard reporting and business intelligence tools and ensures schema integrity by using core database features.

• Validation of integration models. Once a modeler has finished the design a comprehensive model validation takes place guaranteeing model consistency avoiding runtime errors to the extent possible.

Reuse of data and process definitions provides consistency across integration design, reduces the testing effort significantly, avoids costly model duplication and enhances integration model stability.

INTEGRATION CONCEPTS

OVERVIEW

Oracle9iAS Integration 9.0.4 introduces a complete set of integration concepts that are discussed in the following. These integration concepts are implemented by Oracle9iAS Integration 9.0.4's architecture. An integration modeler has the integration concepts as modeling elements available to him in form of modeling interfaces to define A2A (application-to-application) integration, B2B (business-to-business) integration or integration combined of A2A and B2B. Modeling integration is a design time activity. Once the modeler defined integration he has to deploy it to make the modeling data available for production use. After deployment integration is executed by the Oracle9iAS Integration 9.0.4 architecture. The Oracle9iAS Integration 9.0.4 architecture interprets the various integration concepts and implements their behavior. Executing integration is a run time activity. The main fundamental integration concepts can be separated into the following areas:

• Event

• Role and process

• Party These three fundamental integration concepts build the foundation of Oracle9iAS Integration 9.0.4. A party is the abstraction defining sources and targets that need to be integrated with each other. A trading partner or a back end application are two specializations of a party. Events are caused or consumed by parties and are managed within Oracle9iAS Integration 9.0.4. Events are indications of state changes within parties that require a reaction from other parties. For example, a create purchase order is such a state change and expresses a specific intent, namely to purchase a product. Processes define how events are executed, for example sending an event from a trading partner to a back end application requiring user approval along the way. In the following the main integration concepts are introduced in a narrative way that explains not only the integration concepts but also how they are used to achieve particular integration functionality. In addition, a rationale is given why the particular integration concepts have been chosen to be the foundation for Oracle9iAS Integration 9.0.4. The Oracle9iAS Integration 9.0.4 concepts are marked in bold face upon their introduction.

EVENT TYPES AND INSTANCES

An event type is the Oracle9iAS Integration 9.0.4 internal definition of the business relevant data that it manages and that either arrived from a party or that is to be sent to a party. An event instance is an occurrence of a event type and holds actual business data. For example, a particular purchase order for a Boeing 747 or a Mercedes 500 is represented


Paper 32786

as an instance of the event type purchase order. Events represent intents. For example, sending a create purchase order event expresses the intent of buying a product. A party has to react to that intent by either expressing to fulfill it or to not fulfill it. Accepting an event establishes an obligation for proper execution. Several processing stages of events are recognized and distinguished within Oracle9iAS Integration 9.0.4 and those are the reason for different event classes. These are introduced in the following in detail along with related integration concepts. All classes of events in Oracle9iAS Integration 9.0.4 have the same structure.

• An event header stores the meta data necessary to manage event instances at runtime. A header contains the party the event instance is coming from, the party that it has to be sent to, the time of its creation, its life cycle state, a reference to its event type definition and other relevant data necessary for processing it.

• An event can have any number of body elements. A body element carries a complete set of business data. For example, a purchase order like the order of a Boeing 747 would be represented as a body element. A design drawing accompanying the purchase order would be placed in another body element. This allows any incoming set of data to be represented appropriately in structured form making it accessible later on for content processing.

WIRE MESSAGE AND ORACLE RECORD

As for any system it is important to establish the system boundaries of Oracle9iAS Integration 9.0.4. The format of the data outside Oracle9iAS Integration 9.0.4 is not known to Oracle9iAS Integration 9.0.4. However, in order to be able to refer to the data representation outside Oracle9iAS Integration 9.0.4 a term is introduced for it. It is called wire message. The direction of wire messages coming from parties is called inbound. The direction of wire message sent to parties are called outbound. The term wire messages refers not only to 'real' messages like e-mail messages or queue messages but also to synchronous invocations like an remote procedure call to an SAP system. In general, wire messages follow a particular message layout defined in message packaging approaches like MIME or marshaling rules in case of remote procedure calls of programming languages. Some follow a particular encoding and/or are encrypted and/or are signed. In Oracle9iAS Integration 9.0.4 the boundary on a conceptual level is established by a concept called Oracle Record. Data that are received from a party have to be represented as a Oracle Record on the Oracle9iAS Integration 9.0.4 system boundary. Wire messages received from parties are represented as Oracle Record. An Oracle Record that needs to be delivered to a party is represented as wire message and sent out. Once a particular set of data arrived it is represented in an Oracle Record instance. An Oracle Record instance represents the occurrence of data coming from a party or to be sent to a party. The directions inbound and outbound apply to events, too. Only when wire messages are represented as a Oracle Record they can be processed by Oracle9iAS Integration 9.0.4. The definition of the concept Oracle Record is based on the J2EE Connector Architecture standard [java.sun.com/j2ee/connector]. Since the standard is essential in the area of integration this concept was adopted. However, the definition of an Oracle Record is a rather technical definition and not on the right level of abstraction for integration in general. In order to raise the level of abstraction to make the Oracle Record useful the concept of native event is introduced. In terms of the example the wire messages are the web service invocations that have to take place in order to obtain the credit approval.

NATIVE EVENT

A native event is the Oracle9iAS Integration 9.0.4 internal implementation of the business data contained in an Oracle Record. Wire messages can contain any number of parts like payloads, attachments or trailers. Once the wire message is represented as an Oracle Record instance, the individual parts are accessible separately in structured form. This allows to put the different parts into the different body elements of a native event instance. The representation of the contents itself does not change. If a binary data structure is sent it will still be a binary data structure in the body element of a native event instance. Once an Oracle Record instance is represented as a native event instance an important first event abstraction is achieved. The native event instance's body elements contain the data as sent in the wire message. However, the


Paper 32786

particular wire message transmission structure is removed (like encoding, packaging, signing or encryption). All what remains in the native event instance's body elements is the raw data as transmitted. Since the raw data are in their native format as sent by the party the event class is called 'native'. In the outbound direction native event instances must contain native format for the target party so that the appropriate Oracle Record can be created and sent out as a wire message. Since native events contain native formats Oracle9iAS Integration 9.0.4 cannot interpret the contents. Later on through a concept called translation the content of native events is made interpretable by Oracle9iAS Integration 9.0.4 (see Application Events below).

NATIVE EVENT VALIDATION

Every enterprise is concerned about the consistency of wire messages coming in or going out. Validation rules are defined that need to be enforced to guarantee data consistency. The concept of native event validation is provided for this purpose. Each native event type can be augmented with native event validation rules that are invoked at native event instance creation time. If the validation rules can be satisfied then the native event instance is considered consistent and made available for further processing. If at least one of the validation rules fails the native event instance is considered inconsistent. In the outbound case the native event instance is put into the error state. Once it is in error state specific error handling can be modeled that allows dealing with the error situation. In the inbound case the native event instance will not be created and the error is given back to the architecture component that tries to create the native event instance (i. e. the adapter framework, see below in the architecture section). It can then react appropriately by possibly notifying the sending party about the inconsistency. Native event validation rules can access every body element and can be of arbitrary complexity. This includes checking the existence of elements, specific values, cross-element checks, enumeration checks and so on. There is no limit to what can be checked and therefore native event instance consistency can be guaranteed by Oracle9iAS Integration 9.0.4 according to the native event validation rules.

NATIVE ROLES

In general, wire messages exchanged with parties are not one-way wire messages that are sent in isolation. While this is one possible case, it is not the normal or 80% case. The situation in general is that wire messages follow a message transmission pattern. This means that there is a sequence of wire messages sent back and forth between parties. Expressed in terms of native events, usually a native event that is received causes another native event to be sent. Or, a native event that is sent out will cause a response being sent back. The initial native event that starts a message exchange is called an initiating native event instance. Other native events will be communicated based on an initiating native event. Any number is possible. As example the credit approval request (CAR) and credit approval acknowledgment (CAA) exchange is introduced throughout this section. A selling enterprise sends out an initiating native CAR event to check the creditworthiness and will later on receive an incoming CAA native event. Since the wire exchange transmission is unreliable in the general case due to lack of transactional communication infrastructure additional acknowledgment wire messages (ACK) are exchanged to indicate the receipt of other, already sent wire messages. For example, the CAR wire message as well as the CAA wire message are each acknowledged with ACK wire messages. This means in total that there are four wire message exchanges, the CAR, the CAA as well as two ACK messages. In terms of native events that results into four native events, CAR, CAA and two ACK native events. In order to express this dependency the integration concept of native roles is introduced. The term role is chosen since the enterprise exchanging native events (through wire messages) exhibits a specific behavior (role) like buyer or seller. Native roles support the modeling of native event exchange behavior. A native role has a set of processing steps inside that defines the processing of native event instances. Figure 1 shows a native role for the four native events of the above introduced example. The native role implements the buyer behavior. This can be seen because the native CAR is sent out as initiating event (first one). At runtime a native role instance is created for each exchange. The different concepts shown are introduced in the following.


Paper 32786

Native Role

Native Role Step Data Flow Control Flow Native Event Role Port

NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

Figure 1 Native events and native role

• Native role. The native role is the unit that defines the exchange behavior of native events between two parties from the viewpoint of one party. By convention, the left side of the native role is the outbound direction to a party. The right side is the inbound direction to further model elements (introduced later on).

• Native role port. A native role port represents an input or output parameter of a native role containing native event instances at runtime. The ports on the left of the native role are connected to Oracle Records, i.e. the boundary of the system (by the modeler). The native role ports on the right will be connected later on to other ports for further processing (see below). The native role as shown in Figure 1 has four input and four output parameter. Ports are typed by native events and the name of the native event types are shown next to the ports. At runtime only native event instances of this type can be in the ports.

As a naming convention ports are distinguished the following way. Incoming ports are those that receive an event instance from the outside of the role. Outgoing ports are those that receive event instances from within a role. The same convention applies to step ports, too (see below).

• Step. A step defines some execution logic that is applied to one or more native events. The steps in Figure 1 do not apply any execution logic. Instead they pass on the native event instance without any processing. Steps of this type are called pass-through steps. Later on more 'interesting' steps are introduced like transformation or conditional branching.

• Step port. Step ports are the input and output parameter of steps. The first step has one input parameter and one output parameter, both of type NE_CAR ('NE' standing for native event).

• Data flow. The data flow relationship connects ports. For example, the incoming port of native event type NE_CAR is connected to the incoming step port of the first step. This means that at runtime the native event instance put on the incoming role port will be made available to the incoming step port. This behavior is precisely analogous to binding actual and formal parameters in method invocations of a programming language.

• Control flow. The control flow relationship between steps indicates their execution order. As can be seen in Figure 1, the control flow relationship and the data flow relationship are not necessarily relating the same pairs of steps. The figure contains only sequential relationships that enforce the sequential execution of the steps. More complex control flow relationships like conditional branching, loops or parallelism are available.

Native event validation is not explicitly modeled as steps since the native event validation rules are applied when the native event instance is created. If the native event instance is inconsistent the native event instance will not be put into ports in the first place.


Paper 32786

Native roles implement native event exchange behavior because they control which native event instance is to be processed when and in which order. Sometimes they are termed 'public processes' since they implement the publicly visible behavior in context of B2B integration. However, this would be a misnomer in context of A2A integration, therefore this term is not used. In context of the example the native role in the end sequences the web service invocations in order to perform the credit approval. Since native events correspond to wire messages, the native role governs their execution sequence.

NATIVE EVENT CORRELATION

If a seller sends out several CARs then the seller expects to receive the same number of CAAs back (in the normal non-error case). Each CAR-CAA pair (with the necessary ACK events) is executed by its separate native role instance. After a CAR is sent out the native role instance is waiting for the CAA to come back. It might be that several native role instances are waiting for 'their' CAAs to come back. Once a CAA comes back Oracle9iAS Integration 9.0.4 has to determine to which of the waiting native role instances it belongs. If it is possible to relate the incoming CAA with its corresponding CAR then the waiting native role instance can be determined since it is known which native role instance sent out the CAR earlier. The concept to achieve this is called native event correlation. A native event correlation is expressed in an expression that defines when two native event instances are related. For example, an expression can be CAR.request_id = CAA.request_id. This expression says that a CAR and a CAA are correlated if they contain identical credit request identifiers. Once a CAA comes back the expression is used to find the correlated CAR. Once the CAR is found the waiting native role instance can be found that sent out the CAR. The CAA has to be given to that native role instance in order to have the same native role instance process the corresponding CAA for the CAR. Native event correlation based on correlation expressions therefore ensures that the right native event instances are 'matched up' and provided to the corresponding native role instances.

EVENT MAP

Some parties represent many different business relevant events within the same message structure. This results in the same type of wire message being sent that contain different types of business data. For example, instead of having three different types of payloads for creating, updating and deleting a CAR only one type is defined. That type contains a field, sometimes called 'action field' that indicates if the contents is to be seen as a create, update, or delete. If this situation occurs it is necessary to find out at runtime based on the Oracle Record which type is meant. For example, if a purchase order payload comes in through a wire message the Oracle Record will contain the content. At this point in time it must be found out if the purchase order payload is meant as a create, update or delete. Based on this outcome a native event instance representing either a create CAR, update CAR or delete CAR is created. The concept that allows to make this distinction is called (native) event map. An event map consists for each type of Oracle Record an expression that determines the native event type for a given instance of this Oracle Record. Once the Oracle Record is made available the event map applies the expression to it. The expression results in one native event type. Once this is determined an instance of this native event type is created and populated. If an Oracle Record maps only to one native event type the event map is simple. The expression is degenerated to 'true' and the map has only one entry.

PARTY AGREEMENT AND HOSTED TRADING PARTNER

In addition to all the parties like trading partners and back end applications there is one specific party called out, the hosted trading partner. The hosted trading partner is the organization or enterprise that runs Oracle9iAS Integration 9.0.4 in its data center, owns all the integration definitions and that connects to its trading partners or back end application systems using Oracle9iAS Integration 9.0.4. In order for the hosted trading partner to send or to receive wire messages party agreements have to be in place. A party agreement defines which type of native event can be sent or received from a particular party using which particular native role. In more specific concepts, a trading partner agreement defines which native events can be received from a trading partner and which ones can be sent to a trading partner from the viewpoint of the hosted trading partner. A trading partner agreement is established between two trading partners in order to define their rules


Paper 32786

of engagement. Only those native events that both trading partners agree on are exchanged through wire messages. If a trading partner sends a wire message that does not result in an agreed upon native event it is rejected. If the hosted trading partner tries to send a native event to a trading partner and the native event is not defined in a trading partner agreement, the send will fail since Oracle9iAS Integration 9.0.4 enforces party agreements. An application agreement defines which native event can be sent to or can be received from an application - again from the viewpoint of the hosted trading partner. Oracle9iAS Integration 9.0.4 enforces application agreements like trading partner agreements and ensures that only the agreed upon events are sent out or are received.

APPLICATION EVENT AND TRANSLATION

In order for Oracle9iAS Integration 9.0.4 to be able to interpret the contents of native event element bodies (called native format) the contents has to be re-represented in a format (i.e. syntax) that can be processed by Oracle9iAS Integration 9.0.4. This format is called application format and this format can be interpreted by Oracle9iAS Integration 9.0.4. Amongst several possible formats Oracle9iAS Integration 9.0.4 has chosen to represent the event instance structure in relational form and the body elements of event instances in an Oracle9iAS Integration 9.0.4 specific XML dialect. For example, if a CAR is received that is represented as a comma delimited native format then Oracle9iAS Integration 9.0.4 is not able to extract values of it. However, this is necessary when based upon specific values control flow decisions have to be made later on in the business process (see the section on business process below) or if it has to be transformed (see section on transformation below). Once the native event is represented as the corresponding application event Oracle9iAS Integration 9.0.4 can extract values from it and can make decision based on it or transform it. The explicit re-representing of the native format in application format is called translation. For a given pair of corresponding native event type and application event type there is a translation that re-represents the contents of the native event in the native format as an application event in the application format. Translation only re-writes the syntax, not the particular data values. For example, if the native format contains an address as one long big string the application event will contain the same long big string's content. However, if the native event's address is in binary representation then the address will be in the application format in the application event. The internal structure of application event body elements is defined through application data types. Application data types are a structured type system with primitive types like string or integer and complex type constructors like records. Translation translates from the native format into the application format that is defined by the application data types. These application data types allow Oracle9iAS Integration 9.0.4 to access the contents for further processing. At this point in the event processing a second very important event abstraction is achieved. The particular native format is 'neutralized' and by looking at the contents of application event body elements it cannot be inferred any more what the particular native format was. Any specific syntactic property of a party is removed at this stage. For example, if the wire message contained business data in binary form then this is removed at this stage. Instead, the business content is represented in the application format (i.e. the Oracle9iAS Integration 9.0.4 specific XML dialect). The only specific property that remains is the particular vocabulary a party uses. That is going to be abstracted from through transformation (see section on transformation below).

APPLICATION ROLE

Like native events the corresponding application events are sent back and forth between parties in a particular sequence. This sequence has to be defined in Oracle9iAS Integration 9.0.4 and the similar modeling elements are available for it as for native events. Figure 2 shows the application role for the previous example. The same symbols are used for roles and events. However, roles that process native events are native roles and roles that process application events are application roles.


Paper 32786

Native Role

Role Step Data Flow Control Flow Event Role Port

NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

AE_CAR

AE_ACK

AE_CAA

AE_ACK

AE_CAR

AE_ACK

AE_CAA

AE_ACK

Application Role

Figure 2 Translation binding role

In Figure 2 the native role and the application role are not connected with each other yet. Furthermore, the translation steps are not modeled yet that translates native events to application events and vice versa. In order to model this the concept of a translation binding role is introduced next.

TRANSLATION BINDING ROLE

The translation binding role connects the ports of the native role to the ports of the application role. The connection is a data flow connection and along the way the native events are translated into application events and vice versa. Due to the binding nature of the translation binding role it is special in the sense that it can only exist in conjunction with its related native and application role. Hence, the graphical representation is different and the translation binding role is represented as a dashed box. Translation is executed within so-called translation steps in the translation binding role. These are marked 'TL' in the graphical representation in Figure 3.

Native Role


NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

AE_CAR

AE_ACK

AE_CAA

AE_ACK

AE_CAR

AE_ACK

AE_CAA

AE_ACK

TranslationBinding Role Application Role

TL

TL

TL

TL

Figure 3 Translation binding role


Paper 32786

At this point the question arises what to do if the ACKs are only needed in the exchange between a trading partner but not within the enterprise. Is there a way to consume incoming ACKs as early as possible and produce outgoing ACKs as late as possible in order to reduce the amount of processing? The next section will show a solution to this requirement.

ACKNOWLEDGMENT CONSUMPTION AND GENERATION

The earliest place to consume an inbound ACK is the native role. The ACK has to be received from the sending party. Therefore a role step has to be in the native role that processes the ACK. However, instead of passing it on to the translation binding role, it can be consumed within the native role. If this approach would be followed, the native role would not pass on the native ACK event to the translation binding role. While this is the most efficient approach it would not work if the native role is reused for another case where the ACK is needed. Therefore, if reuse is of concern, the ACK should be consumed in the translation binding role. In this approach the native role preserves its original behavior and the translation binding role in another scenario can again consume the ACK if necessary. Generating an ACK requires access to events out of which the ACK is generated. The only place where event content is interpretable by Oracle9iAS Integration 9.0.4 so far is the application binding role (application events) or the translation binding role (application events of it). Again, a design decision has to be made where to do the ACK generation. For illustration it is decided that the generation is done in the translation binding role, too. Figure 4 shows the overall situation.

Native Role


NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

AE_CAR

AE_CAA

AE_CAR

AE_CAA


TL

CM

TL

GN

Figure 4 ACK consumption and generation

The consuming step is called 'CM' in Figure 4. The generating step is called 'GN'. In order to generate the ACK the generation step needs the original AE_CAA event. Therefore an additional data flow is added to an input port of the generation step. Figure 4 also clearly shows that the native role remained unchanged. That was the design goal initially. Also, the application role does not have to deal with ACKs at all. This is nice since it confines the ACK handling in the translation role. This example shows the ability to achieve a very important abstraction: behavior abstraction. The translation binding role abstracted from the ACK handling that was imposed by the particular party that required ACKs. However, for the business ACKs might not be relevant on the business level, only on the protocol level. This means that with translation binding roles the transport related handing of ACKs can be abstracted from. As a result, the application role became a lot simpler with less modeling constructs.


Paper 32786

It is important to note that behavior abstractions are different from event abstractions. However, both are achieved concurrently by means of the way the role set is modeled with the corresponding event classes.

BUSINESS EVENT

A third and final event class is called business event. The immediate question is why another event class is needed. Fundamentally, a business event is required to establish common event structure and common event vocabulary across all parties. For example, if one party uses 'car' and another party uses 'vehicle' to refer to the same product then a vocabulary mismatch exists between the two parties. Whenever an event is sent from the one to the other party 'car' needs to be replaced by 'vehicle' and vice versa. Transformation (see section on transformation below) will achieve this. But does this require a third event class? Why is the transformation not done directly between application events since the application event content is interpretable by Oracle9iAS Integration 9.0.4? The answer lies in the scalability problem that arises with four and more parties. If we assume that four parties exchange events then two transformations have to be defined between each pair of parties. This means 12 transformations in total if direct transformations take place. However, if each of the four parties would transform only to and from a common business event then only 8 transformations are necessary, two for each party. The benefit is immediately clear since the number of transformations is reduced significantly. If transformations for 10 parties have to be defined then only 20 transformations have to be build instead of 90 transformations. The break even is with three parties. In this case 6 transformations have to be defined in the case with business events. The next section introduces transformation in more detail.

TRANSFORMATION

A business event has to be defined in such a way that all corresponding application events from all the involved parties can be represented in it. This means that a common structure has to be found between the application events. For example, assume that one application event type has one long big string containing the credit amount to be authorized, the name of the company which credit needs to be checked and the name of the company requesting the check. Furthermore assume that the application event of a second party needs the credit amount in one element and the two companies in one long big string. A third party might require each data item in a different string. How would the business event look like? The business event would have each data item in a separate string. Transforming from the application events to the business event would mean to split the strings into their individual parts where necessary. Transforming from the business event to the application events would mean to compose strings where necessary. In addition, a vocabulary has to be defined so that all application events are transformed into this vocabulary. For each data item it has to be defined if its value can be preserved in the business event or if a conversion needs to take place (like from 'car' to 'vehicle'). Maps that relate the values like 'car' to 'vehicle' are called domain value maps. A lookup has to take place for conversions. For example, given 'car' the corresponding value 'vehicle' can be looked up. A transformation rule is a prescription of how to transform one data item from an application event to a business event. For example, a transformation rule might be BE_CAR.credit_amount := AE_CAR.credit_amount. This transformation rule copies the value from a data item called 'credit_amount' in the application event to the data item called 'credit_amount' in the business event. More complex transformation rules like conditionals, domain value map lookup and iteration are available. A transformation map is the set of all transformation rules necessary to transform a business event from an application event or vice versa. Transformation maps can have any number of sources and targets. Sources and targets can be application events, business events or data types. At this stage a third important event abstraction is achieved. Business events completely abstract from any party specific properties, including structure of the data as well as vocabulary. All related events from all parties follow the same structure and the same vocabulary once they are translated and transformed into business events.

BUSINESS ROLE

Business events like application and native events before have a specific behavior in the sense that they are processed in a specific order. Business roles are the means to define the execution order for the enterprise, independent of the


Paper 32786

application roles bound to it. Figure 5 shows the business role for the example. The business events are named with the prefix 'BE'. However, this is only by convention to ensure the clarity of the representation.

Native Role


NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

AE_CAR

AE_CAA

AE_CAR

AE_CAA


TL

CM

TL

GN

BE_CAR

BE_CAA

Business Role

BE_CAR

BE_CAA

Figure 5 Business Role

The missing part, the transformation binding role, is introduced in the next section.

TRANSFORMATION BINDING ROLE

Following the same pattern as before, transformation binding roles are binding application roles to business roles and are the 'home' of the necessary transformation steps. The transformation steps are named 'TF' in Figure 6.

Native Role


NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

AE_CAR

AE_CAA

AE_CAR

AE_CAA


TL

CM

TL

GN

BE_CAR

BE_CAA

TransformationBinding Role Business Role

TF

TF

BE_CAR

BE_CAA

Figure 6 Transformation binding role

All the roles in Figure 6 are called a role set. All roles and all event classes up to the business roles achieve the three levels of abstraction. The business role is the highest level of abstraction and is agnostic to any party specific properties. This includes event abstractions as well as behavior abstractions.


Paper 32786

In order to further emphasis the power of these abstractions a second role set is introduced leading up to the same abstractions. This can be the case if another party has a different protocol and different types of wire messages dealing with CAR and CAA. To keep it simple, this additional party does not require ACK events, but has a different representation of CAR and CAA requiring its own set of transformations. This is denoted by CAR' and CAA'. It is important to note that by adding another role set the already existing role set remains unchanged. This is important in a business environment where adding and removing parties happens frequently. Figure 7 shows the additional role set required. Figure 7 is constructed additive, i. e. the additional role set is put on top of the existing role set.

Native Role


NE_CAR

NE_ACK

NE_CAA

NE_ACK

Step Port

AE_CAR

AE_CAA

AE_CAR

AE_CAA


TL

CM

TL

GN

BE_CAR

BE_CAA

TransformationBinding Role Business Role

TF

TF

BE_CAR

BE_CAA

Native Role

NE_CAR' AE_CAR'

AE_CAA'

AE_CAR'

AE_CAA'


TL

TL

TransformationBinding Role

TF

TF

NE_CAA'

BE_CAR

BE_CAA

Figure 7 Additional role set for another party

The important observation for the additional role set is that after the transformation binding role the same business events are available and the same business event sequence. This allows to reuse the business role as indicated in Figure 7. Later on when designing business processes this is an important situation since the business processes does not have to distinguish between party specific behavior (see section on business process below).

BUSINESS PROCESS

The business process is at the center of any integration and implements the business logic as required by the hosted trading partner. For example, if the amount of the credit approval request exceeds a certain limit specific steps have to


Paper 32786

be taken compared to when the amount does not exceed the limit like the approval of two senior supervisors instead of one to send out the credit approval request. This business logic is completely independent of where the request is sent to and which particular behavior the wire messages have for a given party. Since business roles ensure homogeneous behavior of business events as well as their homogeneous structure and content the business process is written in a homogeneous environment. Figure 8 shows the business process for the example above. Later on it will be connected to business roles.

Role or BusinessProcess Step Data Flow Control Flow Event Role Port Step Port

BE_CAR

BE_CAA

Business Process

BE_CAR

BE_CAA

A1

A2

LC

t

f

Figure 8 Business Process

The step 'A1' denotes the mandatory approval that has to take place for every outgoing CAR. 'LC' denotes the limit check step that tests if the approval amount exceeds a certain limit. If this is the case then the second approval has to take place ('A2'). 't' denotes the TRUE branch and 'f' the FALSE branch that has to be taken according to the result of the 'LC' step. Figure 9 links the business process with the business role that implements the behavior for trading partners as introduced above. Only the business role is displayed, not the whole role set.


BE_CAR

BE_CAA

Business Role

BE_CAR

BE_CAA

Business Process

BE_CAR

BE_CAA

A1

A2

LC

t

f

Figure 9 Business Process and one business role


Paper 32786

At this point the business process is connected with the role set for the trading partners. According to Figure 7 two different B2B protocols and their corresponding translations and transformations are available. In the example a back end application is the source of the CARs and the target for the CAAs. In order to connect to the back end application another role set has to be modeled that implements the transformation and translation required for it as well as the wire exchange behavior. This is not done in this white paper any more in detail. One can imaging that this role set looks similar to the one without the acknowledgments since the connection to the back end application is transactional not requiring any transport level acknowledgments.

EVENT ADDRESSING

Events originate from parties and are sent to parties. At some point in the event processing the event addressing has to be accomplished. There are several possibilities to accomplish the event addressing. The first possibility is that the sending party already sets the target party. For example, a back end application system sets the to party where the event should be sent to. This could be another back end application system or a trading partner. In this case the modeler does not have to do any explicit modeling of the target party. Oracle9iAS Integration 9.0.4 will use the target address to deliver the events through the appropriate role sets. However, if he wants to overwrite the suggested address then the modeler can do this. A particular step is available to the modeler for overwriting the target address. A second possibility is that the sending party does not include a final destination in form of a party but names the hosted trading partner as the address. In this case the modeler has to overwrite the address in order to send the event to the final party (e.g. a back end application system or a trading partner). A third, related possibility is that the sending party does not include a target party at all. Again, the integration modeler has to set the party in this case so that the event can be delivered. Figure 10 shows an example where a party is set in a business role. The step 'SP' indicates that a party is set.


BE_CAR

BE_CAA

Business Role

BE_CAR

BE_CAA

Business Process

BE_CAR

BE_CAA

A1

A2

LC

t

fSP

Figure 10 Example of a set party step (SP)

As Figure 10 shows, an outgoing BE_CAR could take two paths since there are two role sets. The question is, which path is taken? Since each path implements finally a different wire message exchange sequence the choice has to be correct for the target party, in case of the example the target trading partner. The party agreement defines which event can be sent to a party using which particular role set. This information is used by Oracle9iAS Integration 9.0.4 to determine which role set is taken after the business role in an outbound direction.


Paper 32786

PRODUCT ARCHITECTURE

OVERVIEW

Oracle9iAS Integration provides a components-based, scalable and reliable transactional architecture that implements the concepts introduced earlier. The architecture follows the traditional layered approach of a user interface layer, a logic layer and a data storage layer. This is shown in Figure 11.

IntegrationTools

AdapterFramework

Adapter

AdapterRun-Time

BLL

Design-TimeRepository

Run-TimeRepository

DataStorageLayer

LogicLayer

UserInterface

Layer

SystemManagement Tool

Figure 11 Oracle9iAS Integration's layered architecture

DESIGN-TIME REPOSITORY

The design repository consists of metadata that captures the definition of all the concepts introduced before. It also captures profile information such as application and trading partner specific metadata and party agreement details. In addition, the design repository also stores configuration information about adapters, translators, event validation modules and B2B protocols and semantics. This allows the user to re-use existing design in new integrations, validate and check the integration prior to deployment. Profile information verification and agreement negotiations happen at design time. All modeling data is captured in the design-time repository in a single normalized relational schema. Some of the benefits this provides are:

• Versioning • Lifecycle management • Fail-over support (RAC) The act of deploying an integration signifies the end of design of modeling an integration configuration. The versions of the Meta data in the configuration are frozen after successful deployment. Any change of those meta data will create a next version enforcing model consistency.

RUN-TIME REPOSITORY

The deployment of an integration results in the creation of the necessary metadata in the runt-time repository for the runtime engine to execute the integration. Any change to integration must be made at design time and re-deployed. This approach ensures run-time consistency because every run-time change has an equivalent design-time change as necessity. Changes to a runtime configuration may be made through Oracle Enterprise Manager. The granularity of deployment is a business process and all the meta data the business process requires to execute properly like event type definitions or transformation maps. The runtime repository consists of a complete set of metadata necessary for a given integration. At run-time the instance data and execution states are captured in the runtime repository.

ADAPTERS

The interfaces provided by all the potential parties that participate in integration vary a lot. Parties can expose many


Paper 32786

different interfaces; examples are synchronous API’s, asynchronous API’s, databases, screen scraping, transactional behavior, JCA, and so on. Adapters know about one or more interfaces of one or more specific parties. There are different types of adapters that can be distinguished:

• Application adapters know how to connect to a specific application and exchange wire messages with it. Examples of applications adapters are the SAP adapter or the Siebel adapter.

• Technology adapters know how to connect to a specific technology. Examples of technology adapters are the database adapter and the AQ adapter.

• B2B protocol adapter is a generic purpose adapter that knows how to connect to a trading partner using standard B2B protocols. Examples of B2B protocols are RosettaNet and HL7.

Figure 12 shows the adapter framework and some adapters.

AdapterFramework

Party AdapterJCA

WireMessage

Party AdapterJCA

WireMessage

. . . . . .

Figure 12 Adapter framework with adapters

In the inbound case an adapter is responsible for receiving the wire message and using the J2EE Connector Architecture (JCA) to hand over the Oracle Record to the adapter framework. In the outbound case the opposite needs to be accomplished: receiving an Oracle Record from the adapter framework and delivering it as a wire message to a party.

ADAPTER FRAMEWORK

The adapter framework is the process that manages the adapters and is responsible to get the Oracle Records in and out of the run-time component of IP. The key benefit of this architecture is that to the runtime every Oracle Record enters the system in exactly the same way, while the adapters deal with the different protocols, like for example synchronous connections, asynchronous connections, and so on. Multiple adapter framework instances can run in parallel to provide scalability. The adapter framework runs completely stateless, which allows recovery after fail over. Figure 13 shows the adapter framework in detail.


Paper 32786

Run-Time

OracleRecord

AdapterFramework

AdapterJCA

AdapterJCA

. . .

Figure 13 Adapter framework, adapters and the runtime component of iP

In the inbound case the adapter framework invokes the run-time to deliver an Oracle Record. In the outbound case the adapter framework invokes the run-time to pick-up the next available Oracle Record and delivers it to the adapter.

RUN-TIME

The run-time environment provides the technology stack with the different integration components required to execute the modeled integration configuration. Figure 14 shows the individual components. In the following the interactions between the components are explained for an inbound event.

Business ProcessManager

EventManager

PartyManager

IntegrationManager

TransformationCorrelationManagerValidation Role

Manager

Run-TimeRepository

1 3 4 5 7 8 9

TranslationEvent MapManager

2 6

Run-Time

AgreementManager

10

Figure 14 The technology stack components of the runtime component of IP

The integration manager coordinates the execution. After receiving an Oracle Record from the adapter framework the event manager (1) has to create the native event instance in the run-time repository. The event map manager (2) is invoked to determine the right native event type for the Oracle Record. Validation (3) is invoked before the native event instance is created to prevent the processing of invalid events. If the native event instance is not valid it is rejected within the same synchronous invocation of the adapter. If the native event instance is valid it is stored in the run-time repository for further processing (at the same time providing auditing). The integration manager will detect a new native event instance in the run-time repository and tell the role manager (4) about it. The role manager has to either initiate a new native role instance or continue an existing one. The correlation manager (5) is invoked to determine if this native event instance is correlated to a native event instance used in any of the already initiated native roles instances. If this is the case the native event will be handed over to the existing instance and get processed. If not a new native role instance will be initiated that processed the new native event. The integration manager will now tell the role manager about the native event that has been processed by the native role and needs to be processed by the translation-binding role. Within this role a translation step is defined. This causes the translation component (6) to be invoked and translate the native event to an application event. After


Paper 32786

translation the role manager is invoked again to continue processing of the translation-binding role. Next, the integration manager will invoke the role manager to process the application role and after that the transformation-binding role. In the transformation-binding role a transformation step will be defined that causes the transformation component (7) to be invoked. After transformation the role manager has to finish processing the transformation-binding role and is invoked to process the business role. The business process manager (8) is invoked to process the business process. After processing the business process the same architectural behavior applies in the outbound direction. Typically, the target party is known or has to be set in the business role on outbound by using the party manager (9). Given the party the agreement manager (10) is used to lookup what native role needs to be used for this particular party (one party could use RosettaNet and another party could use HL7, both having different behaviors that are modeled in different native roles). Once the native role is known the business role can figure out what transformation binding role needs to be used.

BUSINESS LOGIC LAYER (BLL)

Every user interface tool of IP uses the BLL to exchange information with Oracle9iAS Integration 9.0.4. The BLL ensures that only valid information enters the system, which provides consistency to the concepts to be modeled. For example, it ensures that an event type always has a header and body elements of known data types.

INTEGRATION TOOLS

Oracle9iAS Integration 9.0.4 has chosen to provide a single integration tool in HTML with the 9.0.4 release. HTML provides the easiest ability of remote access across firewalls without the need of any client software installation or configuration. Seven screen shots will show different example screens that are parts of the tools in the following:

• The main entry screen shot shows the five main tool categories. • One screen shot for each category follows:

• The modeling screen shot shows a simple business process. The profiles screen shot shows a list of defined applications. The deployment screen shot shows a list of validation errors that prevented deployment and that require the modeler to change the modeled meta data

• The reports screen shot shows a generic screen to query for errors • The Administration screen shot shows the business protocols supported

MAIN ENTRY SCREEN The main entry screen shows the following five categories: Modeling, Profiles, Deployment, Reports and Administration. Within the screenshot each of the categories is described. To get to this screen sign-on is required that authenticates the user.


Paper 32786

MODELING The modeling screen shot shows a very simple business process. After the starting step the pass-through step receives a business event and passes it on. After the pass-through step is executed the process finishes with the end step. On this screen it is possible to change the business process, choose to also show the event names and zoom-in/out to show more or less details. The sub menus show the next layer of modeling concepts: business processes, roles, business events, interaction and namespaces. Most of these provide a third sub-menu layer to allow modeling all the concepts.


Paper 32786

PROFILES The profiles screen shot shows the applications that are defined in the system. The applications can be updated or deleted and new applications can be added. A search facility is provided as a generic feature on every screen that models the concepts to quickly find what you are looking for. Other profiles that can be defined here are the hosted training partner, external trading partners and agreements.


Paper 32786

DEPLOYMENT The deployment screen shot shows the validation results after an attempt to deploy a modeled integration configuration. The screen shows validation errors, which prevent the user from deploying the invalid configuration. The errors are given with enough details for the modeler to complete the integration configuration correctly. The design task ends with deployment. The deployment creates the necessary Meta data and objects in the runtime engine for the entire integration to run. The physical design environment configures the non-portable part of the definitions. Any physical configuration information, such as machine names, database SIDs, table spaces, etc., can be set when the integration is deployed and the Administration tools allow this to be changed after the integration is deployed.


Paper 32786

REPORTS The reports screen shot shows a generic screen to query for error events in the system. This is important functionality since error situations are extremely important and require attention right away.

ADMINISTRATION This administration screen shows the administration tab and the business protocols being configured. Other administration tasks include adapter configuration and management.

SYSTEM MANAGEMENT TOOLS

Oracle Enterprise Manager (OEM) provides system management. This figure shows the three system instances managed: the Integration Manager, the Adapter Framework and the Design Tool OC4J Instance. OEM starts, stops and monitors the system instances. If there is a problem with any of the instances the administrator can be notified.


Paper 32786

EXAMPLE The following Figure 15 illustrates the example given at the beginning of the white paper.

AdapterFramework

SMTPAdapter

Browser HTTPAdapter

AdapterFramework

CustomerDB

CreditCompany

Web ServicesAdapter

LeadsDB

DatabaseAdapter

Run-Time

Run-TimeRepository

i1

2

3

4

5

6E-mailServer

Figure 15 Architectural view of example

The sales manager uses a browser to enter the prospect information. Through the HTTP adapter (1) an Oracle Record


Paper 32786

is created and handed over to the Run-Time component of IP. Within the Run-Time the event map manager determines what native event instance needs to be created. The event manager creates the native event instance for the provided Oracle Record. The integration manager determines that there is a new native event instance in the system and calls the role manager. The role manager finds out that a new native role instance needs to be initiated for this native event. This native role definition has only one inbound native event in this example and no outbound native events. Going to the abstraction layers as described in the concepts the event ends up in the business process. The business process was modeled in such a way that the event goes outbound to two different parties via two different role sets. One role set is for the database adapter (2) to deliver the event to the leads DB. The other role set delivers a native event to send a credit approval request (3) using the web services adapter. The result of the web services invocation (4), the credit approval acknowledgment ends up as a native event in the runtime. When the result reaches the business process two things happen. First the result of the credit approval request is transformed into an event that is send out as an e-mail to the sales manager (6). Second, the result needs to be checked. If the credit approval was successful an event needs to be created and delivered to the database adapter to create a new customer record in the customer DB (5).

SUMMARY The challenge of integrating disparate applications and integrating with trading partners across the Internet or other networks has proven to be very complex, leading to point-to-point solutions, many different technologies tied together that are hard to maintain and monitor, and different products for A2A integration, B2B integration, Business Process Modeling, Business Activity Monitoring, and so on. To handle this rapid growth of complexity and better manage these critical business processes enterprises are demanding a next generation integration product. Only Oracle can satisfy this demand by offering a single integrated product for A2A and B2B integrations called Oracle9iAS Integration 9.0.4.

O 9IAS: THE SEVEN BASIC CONCEPTS OF INTEGRATION · can satisfy this demand with a single product...

Documents

Transcript of O 9IAS: THE SEVEN BASIC CONCEPTS OF INTEGRATION · can satisfy this demand with a single product...