iWay Oracle Wrapper Architecture

In this section:

The iWay Application Adapter for Oracle E-Business Suite interacts with Oracle APIs through an iWay Oracle wrapper procedure called iway_ora_api_wrapper which is installed under the 'iway' user. The wrapper has two stored procedures- get_api_definition and run_api. These stored procedures are internally executed as 'APPS' user. The following topics describe how the adapter interacts with the wrapper at design time and run time.


Top of page

x
Design Time

The adapter queries Oracle's sys.all_objects table to build the list of packages and stored procedures. When a user navigates to a stored procedure within a package and clicks the 'stored procedure call' node the adapter sends the name of the API in the form of <schema.package_name.stored procedure_name> to call the get_api_definition procedure. The get_api_definition procedure queries the data dictionary in Oracle and retrieves the required information and does the following:

  1. Delete any old values and Insert the parameter information to the IWAY_API_PARAMETERS table.
  2. Build the request_schema and response_schema values and send this information to the adapter. Also the status of the get_api_definition execution is also returned to the adapter in the wrapper_status variable.

The adapter in turn uses this information from the request_schema and response_schema variables to create the request xsd and response xsd schemas and eventually the WSDL.


Top of page

x
Run Time

When a web service is invoked, the XML payload is taken by the adapter and the API name, parameters name, data types, and values are passed to the run_api script in the wrapper. The wrapper then executes the Oracle API and sends the output to the adapter. It also sends any Oracle error messages to the adapter. The adapter displays this output as its response.

Understanding the Functionality of the RUN_API Script

The run_api script receives an input file from the adapter to execute. It uses the api_parameters table to validate the names of the input parameters that are passed from the adapter and to determine the data type for those input parameters. If the metadata does not exist for the given API, it executes get_api_def to check the data dictionary and loads the data into the api_paremeters table.

The wrapper then checks if the dynamic declaration file exists, which is needed to hold the variables for the given API. If the dynamic declaration file does not exist, it is automatically created. The run_api script runs a query against the dba_objects table at the beginning of each execution, which is part of its dynamic declaration processing. The dynamic declaration files are generated in real time.

The dba_objects table is checked during each execution of the wrapper to see if a declaration file exists for the API with a creation date greater than or equal to the API creation date. If this is true, the run_api script goes to the next step. If this is false, the API generates the declaration file. Global variables are then created to store the input parameters. These global variables are represented using the following format:

iway2_xxx.parameter_name

For example:

P_API_VERSION => IWAY2_159656_Process_Items.P_API_VERSION

Next, the input parameter processing routine runs to move the input parameters into the global variables. This includes interpreting the delimiters to properly support tables and record abstract data types. Variables are also prepared in the correct datatype. After all of the input parameters have been processed, the API call string is generated. This is the actual statement that is sent to the API (and is documented each time the log file is executed).

If you review the call string in the wrapper log file, you will notice that it is a simple call string that uses the same syntax you would use if you were calling the API from sql*plus in a pl/sql code snippet. This is the only direct connection between the wrapper and the API. The wrapper then waits for the API to complete and then parses the output from the API into a syntax which can be passed back to the adapter.


iWay Software