Oracle® Application Server Integration Adapter for Tuxedo Installation and User's Guide 10g (9.0.4) Part Number B10459-01 |
|
After the Oracle Application Server Integration Adapter for Tuxedo is installed and the modeling described in Chapter 3, "Modeling Interactions for Oracle Application Server Integration Adapter for Tuxedo" and Chapter 4, "Using Interactions in a Business Process" completed, you can use the Oracle Application Server Integration Adapter for Tuxedo to invoke interactions that access programs under Tuxedo.
This chapter contains the following sections:
Oracle Connect for Tuxedo provides support for all standard types of Tuxedo's message buffers as Input/Output:
STRING - A null terminated character array
CARRAY - An array of un-interpreted arbitrary binary data.
XML - An XML formatted data
VIEW - A "C" structure layout.
VIEW32 - A "C" structure layout where 32-bit FML identifiers are used.
FML - A special Tuxedo system type that provides transparent data portability.
FML32 - An FML type where 32-bit FML identifiers are used.
Unstructured message buffers are wrapped within a record as follows:
The Oracle Application Server Integration Adapter for Tuxedo includes a set of APIs that enable sending a native event as an inbound interaction from a C program.
To use the APIs, you must include the following in the C program:
gap.h
header file - This header file includes all the API declarations
This appendix describes the APIs and functions:
The following functions handle the connection and connection context for an inbound interaction:
There are two kinds of connections:
Transient Connection - Transient connections are created for use within a single inbound interaction. A transient connection is disconnected when an inbound interaction ends, or when the connection context changes (that is, with the connect
, setConnection
or disconnect
functions).
Persistent Connection - Persistent connections can persist across multiple inbound interactions or connection context changes. Persistent connections are disconnected upon an explicit disconnect
function or when a connection idle timeout expires.
The Connect
function establishes a new connection context. All the interactions defined take place within a connection context.
Upon a successful connect, a connection context is established and an implicit setConnection is performed with the newly created connection ID. A failed connect
function leaves the inbound interaction with no connection context (that is, if a connection context was established prior to invoking the connect
function, that connection context will no longer be in effect).
The function returns an integer of 1 (TRUE) or 0 (FALSE), to determine the success of the function.
ACXAPI_CONNECT(char * ServersUrls, char* Username, char* Password, char* Workspace, char* AdapterName, int Persistent, long IdleTimeout, ACXAPI_CONNECT_MODE ConnectMode, char* DefinitionFileName, char* KeyName, char* KeyValue, void **ConnectHandle)
The Disconnect
function destroys the current connection context. All the resources associated with the current connection (persistent or transient) are released.
ACXAPI_DISCONNECT(void* ConnectHandle)
Parameter | Usage | Description |
---|---|---|
ConnectHandle |
Input |
A pointer to the connection |
The Reauthenticate
function establishes a new client identity for the active connection. Adapters are not required to support reauthentication.
An adapter that does not support reauthentication is required to produce an exception if required to reauthenticate with an identity different from the current one. Failure of reauthentication prevents further activity on the connection (other than retrying authentication). Once the reauthentication succeeds, the connection's client is authorized based upon the authenticated identity established.
The function returns an integer of 1 (TRUE) or 0 (FALSE), to determine the success of the function.
ACXAPI_REAUTHENTICATE(void* ConnectHandle, char* Username, char* Password)
The Clean Connection
function indicates that the client is working with connection pooling and that the connection is being 'soft-closed'. That is, the connection is being placed in a connections pool. The connection is still valid but various resources on it are freed (for example, objects related to local interactions).
The function returns an integer of 1 (TRUE) or 0 (FALSE), to determine the success of the function.
ACXAPI_CLEAN_CONNECTION(void* ConnectHandle, int forgetAuthentification)
Transaction APIs are used in the following scenarios:
Non-transacted operation - The adapter works in auto-commit mode. Work is committed immediately and automatically upon execution. This operation mode is the default operation mode when no transaction APIs are used, or when the setAutoCommit
function sets auto-commit to true.
Local transaction operation - When auto-commit is set to false, the first interaction starts a transaction that lasts until an explicit commit (using the transactionCommit
function) or an explicit rollback (using the transactionRollback
function) occurs. All interactions performed in between are part of that transaction.
The following functions handle transaction operations:
The Set Autocommit
function sets the auto-commit mode of the connection.
ACXAPI_SET_AUTO_COMMIT(void* ConnectHandle, int AutoCommit)
The Transaction Commit
function commits the work done under the global or local transaction.
ACXAPI_TRANSACTION_COMMIT(void* ConnectHandle, ACX_XID Xid)
Parameter | Usage | Description |
---|---|---|
ConnectHandle |
Input |
A pointer to the connection. |
Xid |
Input |
For internal use only. Supply an empty value |
The Transaction Rollback
function rolls back the work done under the (global) transaction.
ACXAPI_TRANSACTION_ROLLBACK(void* ConnectHandle, ACX_XID Xid)
Parameter | Usage | Description |
---|---|---|
ConnectHandle |
Input |
A pointer to the connection |
Xid |
Input |
For internal use only. Supply an empty value |
The Execute
function executes a given interaction against the application. The function supplies the input record that is required by the application.
ACXAPI_EXECUTE(void* ConnectHandle, char* InterationName, void* BufferIn, void* BufferOut, long BufferOutLen)
The Get Adapter Schema
function returns the schema of Oracle Connect for Tuxedo's backend adapter.
ACXAPI_GET_ADAPTER_SCHEMA(void* ConnectHandle, void** *Definition)
Parameter | Usage | Description |
---|---|---|
ConnectHandle |
Input |
A pointer to the connection |
Definition |
Output |
The listing of the adapter definition |
The Get Event
function determines the event to wait for and how long to wait. When an event is received, the function returns the results of performing the event.
ACXAPI_GET_EVENT(void* ConnectHandle, char* EventName, long Wait, int Keep, void* BufferOut, long BufferOutLen)
The Ping
function returns, in a pingResponse response, information about an active adapter.
ACXAPI_PING(void* ConnectHandle, void** OutputStruct)
Parameter | Usage | Description |
---|---|---|
ConnectHandle |
Input |
A pointer to the connection |
OutputStruct |
Output |
The return information describing the structure of the adapter |
The Get Error
function returns error information.
ACXAPI_GET_ERROR(void* ConnectHandle, char* *Error, long *Status)
Parameter | Usage | Description |
---|---|---|
ConnectHandle |
Input |
A pointer to the connection |
Error |
Output |
The error message returned by the function |
Status |
Output |
The status of the returned error |
You can configure a pool of server processes so that a server process is always available for a client request.
See Also:
"Configuring the Daemon for High Availability" for details about high availability |
If you encounter incompatibility problems, please contact Oracle Support Services. The following section describes the known restrictions and includes suggestions for dealing with them when possible:
Oracle Connect for Tuxedo handles Tuxedo's data at a record level only. Individual fields cannot be addressed independently.
Specifying a value greater than 1 in the COUNT field of Tuxedo's field definition within a VIEW file, translates to array='xx' attribute
Specifying a value in the SIZE field of Tuxedo's field definition within a VIEW file, translates to size='yy' attribute
Specifying C in the FLAG field of Tuxedo's field definition within a VIEW file, imposes generation of an extra leading COUNTER field to hold the actual count value.
Specifying L in the FLAG field of Tuxedo's field definition within a VIEW file, imposes generation of an extra leading LENGTH field to hold the actual length value.
Specifying a value in the NULL field of Tuxedo's field definition within a VIEW file is not reflected in Oracle Connect for Tuxedo's backend adapter record.
Tuxedo's restrictions with regard to VIEW fields are preserved.
The following is an example of a VIEW definition:
VIEW emp #TYPE CNAME FBNAME COUNT FLAG SIZE NULL long lSalary SALARY 1 - - 0 short nDeptnum DEPTNUM 1 - - 0 short nEmpnum EMPLOYEE_NUMBER 1 - - 0 short nJobcode JOBCODE 1 - - 0 string szMessageText MESSAGE_TEXT 1 - 80 "" string szFirstName FIRST_NAME 1 - 16 "" string szLastName LAST_NAME 1 - 21 "" END
The following is an example of a field table that defines the FML field IDs:
*base 100 # name number type flags comments MESSAGE_TEXT 1 string - - # DEPTNUM 100 short - - EMPLOYEE_NUMBER 101 short - - JOBCODE 102 short - - FIRST_NAME 103 string - - LAST_NAME 104 string - - SALARY 105 long - -
Oracle Connect for Tuxedo does not handle user-defined datatypes.
|
![]() Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|