10g (9.0.4)
Part Number B12121-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle® Application Server ProcessConnect User's Guide 10g (9.0.4) Part Number B12121-01 |
|
With Jacada Integrator®, Oracle Application Server ProcessConnect customers can integrate legacy applications when prebuilt APIs or legacy application source code is not available. Jacada Integrator's J2EE Connector Architecture (JCA) resource adapter for Oracle Application Server ProcessConnect allows applications to create, read, update, and delete records within legacy applications using screen-based access. Jacada Integrator is available from
http://www.jacada.com/products
Jacada Integrator documentation is available from the Jacada Web site and from
http://otn.oracle.com/documentation/
|
See Also:
""Related Documentation" for information on accessing the Oracle Technology Network (OTN) |
This appendix contains these topics:
The Jacada Integrator JCA resource adapter provides connectivity and transactional capabilities for legacy systems. The resource adapter plugs into the application server, providing connectivity between the legacy system, the application server, and the enterprise application. Legacy application platforms supported by Jacada Integrator include mainframe systems running 3270-based applications, midrange systems (AS/400) running 5250-based applications, Unisys, DEC VAX, Data General, Bull, Amdahl, and various UNIX/Telnet systems running character-based (such as VT100, DG400) applications.
The Jacada Integrator MapMaker development tool provides the automated development environment for legacy systems. The MapMaker tool generates code that describes and automates the interaction with the legacy system in a transactional manner. These transactions are called methods, and they are available in the deployed code that resides within the Jacada Integrator JCA resource adapter.
MapMaker is a Java-based application included with Jacada Integrator that enables you to create interfaces to legacy applications automatically. These interfaces are then output from MapMaker as Jacada Integrator Java services for use in the J2EE-based environment. MapMaker is designed to simplify the mapping of legacy application screens into Java application logic. This is accomplished by creating a map of the host application, which consists of the application screens, the navigational information required to traverse through the sequence of screens, and the tags and fields included on each legacy screen. This information is stored in a map file and in Java class files that are produced from within MapMaker.
MapMaker supports English and Western European single-byte and Asian double-byte data streams. However, only 7-bit U.S. ASCII is supported for the names of items, such as screen, tag, and field names, log file names, and map and service names. In addition, only alpha characters (A-Z, upper or lower case), should be used as the first character of most names.
Five basic steps are involved in the development process:
A trail is a linear path of all screens encountered while navigating through a host application in trail recording mode. Each trail is added to the trail repository for the current map, and MapMaker uses these trails to build a comprehensive map of the host application.
Trails contain the following information:
Trail recording exposes MapMaker to all the host screens that are required for the Jacada Integrator service to interact with the legacy application. Since MapMaker is essentially learning how the host application is controlled, it is important to perform all actions that are required to make the host application perform appropriately at runtime.
A trail is recorded by navigating through the host application. During trail recording, you interact with legacy screens using the terminal emulation capabilities of MapMaker exactly as if you were interacting with the legacy application during normal use. This can be accomplished with a single trail or multiple trails using different paths through the legacy application. You can add new trails to a map at any time. MapMaker combines these into a single map.
During trail recording, a snapshot is created for each screen encountered. As the trail is recorded, user inputs (actions) are mapped to their associated screen snapshots. This provides information necessary for the Jacada Integrator service to navigate from one screen to the next within the legacy application.
Screens are the actual rendered image of the legacy application text-based user interface. Screens are composed of fields and data and are saved within MapMaker's map repository. These screen images are used by Jacada Integrator to navigate through the legacy application.
The screen mapping step begins after the trails have been recorded. During this phase, the trails are analyzed by MapMaker to determine which snapshots have the same formatted field layout. Snapshots with the same formatted field layout are grouped together as one "screen" in the map. This grouping is based entirely on the layout of the screen's fields and is independent of the actual text or content of the fields themselves.
While screen content may vary depending on the user input and the data output from the legacy application, screens are still identified based on their formatted field layout. This means that the Jacada Integrator system is always able to recognize a screen, regardless of the contents of the field.
For example, as you input an account number and get customer data from the Customer Information screen, each time a different account number is input, the same Customer Information screen displays the customer data. The same set of formatted fields is used, but the actual data in the fields is different.
After the screens are correctly recognized, you tell MapMaker which fields contain data to be extracted by the Jacada Integrator service. This is accomplished using data templates and table templates. Data templates and table templates use data fields to identify the fields or areas of the screen to be extracted. Data templates are used as containers that map individual fields on the legacy screen. Table templates are containers that map repeating areas of fields on the legacy screen. Often data on legacy screens is displayed in a table format with a varying number of repeating rows, which continues for several pages. Table templates are used to define boundaries of repeating information. The fields in the first row of the table are mapped as data fields and repeat through the entire area defined by the table template.
Methods define how a transaction (for example, opening an account or getting an account balance) is accomplished against the host application. Multiple methods can be created for a single map. Methods define the steps necessary to perform a given transaction against the legacy application by defining the inputs, navigation, data retrieval, and conditional logic needed to perform that transaction.
Method definitions consist of:
The following method steps can be defined within a method:
Traverse: Traverse steps instruct the method to traverse from the current screen to another screen.
Fetch: A Fetch step extracts data from the screen based on the specified data template or table template.
Perform: A Perform step instructs the method to perform a specified action.
Write: A Write step is used to input data to the screen based on the specified data template or table template.
UserInteraction: A UserInteraction step allows the user to navigate the host application manually.
Invoke: An Invoke step provides a means to invoke other methods.
JClient3: A JClient3 step provides a means to invoke methods in other Jacada Integrator services.
Thread: A Thread step provides for parallel code execution within the method.
ThreadJoin: A ThreadJoin step provides a method to collect the threads within the method, and a point of convergence for the parallel code.
Set: A Set step provides the user the ability to assign values to global variables and add data to the return map.
IfCondition: The IfCondition step provides a comparison between two objects. If the evaluation of the condition is true, then the steps on the conditional or <branch> link are executed. If the evaluation of the condition is false, then the primary or <next> method logic path continues. If the true/conditional steps are executed, then the primary method logic path resumes after they have completed.
IfElseCondition: The IfElseCondition step provides a comparison between two objects. If the evaluation of the condition is true, then the steps on the conditional or <branch> link are executed. If the evaluation of the condition is false, (the Else part of the condition), then the primary or <next> method logic path continues. If the true/conditional steps are executed, then the primary method logic path is not followed.
ForCondition: The ForCondition step executes the steps on the conditional or <branch> link, in a loop, based on specified initializer, conditional, and increment settings. When the For loop ends, the primary or <next> method logic path continues.
WhileCondition: The WhileCondition step executes the steps on the conditional or <branch> link based on the specified conditional settings. When the While loop ends, the primary or <next> method logic path continues.
DoWhileCondition: The DoWhileCondition step executes the steps on the conditional or <branch> link based on the specified conditional settings. When the DoWhile loop ends, the primary or <next> method logic path continues.
Services are a runtime container for methods. After creating methods, services are created that represent logical groupings of the methods. Multiple services can be created from one map. Services can also define initialize and finalize methods to be executed when the service starts execution or completes execution. A service can also define a home screen, a screen within the legacy application that the service returns to when a method is completed and the client disconnects.
J2EE Connector Architecture (JCA) defines a standard architecture for connecting the J2EE platform to heterogeneous enterprise information systems (EISs). A resource adapter is defined as the component that plugs into the application server and provides the interface between the connector consumer/client and the EIS.
JCA defines two types of contracts:
JCA defines the service provider interface (SPI), which is the system contract between the resource adapter and application server. The Jacada Integrator JCA resource adapter implements the SPI as described in the JCA specification, including the following contracts:
JCA defines a common client interface (CCI) for EIS access. The CCI defines a standard client API for application components. The CCI enables application components and enterprise application integration frameworks to drive interactions across heterogeneous EISs using a common client API.
The resource adapter exists within the process space of the application server, which interacts and performs connection, transaction, and security management using the system interfaces implemented by the resource adapter. J2EE client applications such as Enterprise JavaBeans, servlets, and JavaServer Pages interact with the resource adapter using the CCI. The resource adapter interacts with the EIS in an EIS-specific manner, which is not defined by JCA.
The Jacada Integrator JCA resource adapter implements the CCI as described in the JCA specification, including the following interfaces:
To obtain more details about Jacada Integrator, visit
www.jacada.com/products/
Or send an e-mail to
info@jacada.com
Or call one of the following Jacada offices:
400 Perimeter Center Terrace, Suite 100
Atlanta, GA 30346
1-800-773-9574
18 Soho Square
London W1D 3QL
+44 (0)20-7025-8077
Werner-von-Siemens-Str. 6
86159 Augsburg, Germany
+49-821-262-8344
|
 Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|
