| Oracle Procedural Gateway® Visual Workbench for WebSphere MQ Installation and User's Guide 10g Release 2 (10.2) for Microsoft Windows (32-Bit) Part Number B19082-01 |
|
|
View PDF |
| Oracle Procedural Gateway® Visual Workbench for WebSphere MQ Installation and User's Guide 10g Release 2 (10.2) for Microsoft Windows (32-Bit) Part Number B19082-01 |
|
|
View PDF |
The Oracle Procedural Gateway Visual Workbench for WebSphere MQ is for developers who are writing Oracle applications that communicate with non-Oracle message queuing applications and who are using an Oracle Procedural Gateway for WebSphere MQ for message queuing.
For detailed information about Oracle Procedural Gateways for message queuing systems, and about message queuing systems in general, refer to the gateway installation guide for your platform.
The following topics are included:
Message queuing systems enable communication between applications. In a message queuing system, an application stores messages in a queue that is accessible to another application. One application sends a message to a queue, and the other application asynchronously retrieves the message and processes the information it contains.
Oracle Procedural Gateways for message queuing systems enable Oracle applications to send messages to, and retrieve messages from, message queuing systems.
The gateway converts Oracle remote PL/SQL procedure calls into calls understood by the message queuing system's interface. Using the gateway, Oracle applications can access non-Oracle applications that are enabled for message queuing.
The Oracle Procedural Gateway for message queuing provides the basic mechanism that enables Oracle applications to communicate with non-Oracle applications using message queuing systems. To write these applications without a development tool like the PG4MQ Visual Workbench, you must:
Write PL/SQL code to call the gateway remote procedure calls that provide communication with the message queuing system
Often write code to handle incompatible data types between Oracle applications and target applications
The PG4MQ Visual Workbench automates these tasks for developers.
The PG4MQ Visual Workbench simplifies the development work necessary to access message queuing applications through the gateway. The PG4MQ Visual Workbench does this by handling data conversion between incompatible data types in messages exchanged between Oracle applications and non-Oracle message queuing applications.
The PG4MQ Visual Workbench has two components:
Visual Workbench
Visual Workbench repository
Use the Visual Workbench to develop interface profiles that contain the information necessary to communicate with other message queuing applications. The Visual Workbench stores the interface profile information in the Visual Workbench repository. Using the Visual Workbench, you compile the interface profile, producing a MIP that contains the PL/SQL code needed for Oracle applications to communicate with non-Oracle message queuing applications in a run-time environment. You provide MIP templates as a starting point for your application to use the MIP, and then compile and test the MIP on the production server.
Figure 1-1 illustrates the PG4MQ Visual Workbench's development and run-time environments.
The Visual Workbench (one for each developer) simplifies the work needed to access message queuing applications through the gateway. Use the Visual Workbench to:
create data profiles
create message queue profiles
create interface profiles
generate a MIP
Test the gateway and compile the MIP in the development environment
Provide MIP templates to use as a starting point for development
Compile the MIP and test it on the production system
The MIP uses the profile information you provide, enabling communication between an Oracle application and a non-Oracle message queuing application.
The gateway and a message queuing system are the transport mechanisms for message data. They provide no data conversion capability. This means that usually you must supply code to convert data between Oracle data types and non-Oracle data types.
Using the Visual Workbench, you create data profiles that, when associated with an interface profile, automatically add the necessary conversion code before a message is sent or after a message has been retrieved. The Visual Workbench maintains the data profiles in the Visual Workbench repository.
To have the interface convert a COBOL structured message to PL/SQL, you create a COBOL data profile defining data conversion definitions. The Visual Workbench generates PL/SQL code to map between the COBOL data conversion definitions and those of PL/SQL. Currently, only COBOL version IBM VS/COBOLII is supported.
Using the Visual Workbench, you define the attributes of the message queues used to communicate between Oracle and non-Oracle applications. A message queue profile specifies how and where inter-application messages are sent to the message queuing system and are retrieved from it.
When a message queue profile is associated with an interface profile, the Visual Workbench generates the PL/SQL code necessary to access the message queuing gateway and stores it in the Visual Workbench repository. "Creating a Message Queue Profile" for details
Using the Visual Workbench Wizard, you combine one data profile and one message profile to define or update an interface profile. The interface profile:
Defines how messages are exchanged with the non-Oracle application, using the gateway and the message queuing system
Defines how message data is converted for communication between the applications
The Visual Workbench uses the interface profile information to generate a MIP, a PL/SQL package that provides a high-level interface between Oracle applications and non-Oracle message queuing applications. To create an interface profile you specify:
One data profile
One message queue profile
A unique name for the interface
The database link for communication between Oracle and a message queuing system, through the gateway
After you have defined the interface profile, the Visual Workbench automatically generates a MIP based on the interface profile information you specified. A MIP is a PL/SQL interface to send messages to, and retrieve messages from, a non-Oracle message queuing system.
When you generate a MIP, the Visual Workbench produces the MIP itself, data conversion code, and templates that show how to access the message queuing system using the MIP.
Using the Visual Workbench, you can install the generated MIP on any Oracle server where your application is running.
|
See Also: "Creating an Interface Profile and Generating a MIP" and "About the Message Interface Package (MIP)" for more information |
The PG4MQ Visual Workbench produces PL/SQL test code in addition to the generated MIP. Use the test code to verify the interaction with the procedural gateway before you compile the MIP on the target server. Using the test code before compiling the MIP helps identify any problems in the interaction with the gateway. It is easier to identify such problems before compiling than when testing the MIP itself.
The MIP and data conversion code must be compiled on an Oracle server before you can use them in your application. After completing the development and testing, use the Visual Workbench to compile the generated MIP on the server you choose for compiling.
The PG4MQ Visual Workbench produces templates for the generated MIP. After you have verified the test code and compiled the interface, you can complete the templates and test them from the PG4MQ Visual Workbench. The templates can be used as a starting point for your application to use the MIP for sending and retrieving messages.
|
See Also: "Creating an Interface Profile and Generating a MIP" and "About the Message Interface Package (MIP)" for more information. For more complete MIP information, refer to Chapter 7, "Using the Generated MIP". |
The Visual Workbench repository stores all data profiles, message queue profiles, interface profiles, and MIPs. The repository resides in an Oracle server and can be created in any Oracle server in the network. The Oracle server used for the repository need not be the same Oracle server that is used in the production system by the applications referencing the MIPs, it can be a different Oracle server.
