This document describes the SOAP Operations and their inputs, exposed by the SOA Gateway to access data sources.
At this point your SOA Gateway Server should be installed, configured and started.
If you have not yet configured any web services, please refer to the SOA Gateway Control Center section and add at least one web service
All web services defined will have a WSDL associated with them. This is the starting point for using the operations provided by the SOA Gateway. The WSDL describes the operations that may be carried out, and how they are used. This includes a description of valid parameters, data and responses for each of the operations.
In order to get the WSDL for a particular resource you simply issue a standard http request, specifying:
the server name or IP-address of the server where the SOA Gateway is installed [ and running ]
the TCP Port number that the SOA Gateway is listening on (as provided in the installation)
the name of the service. (this is the value of the "Name" field in the web service properties)
The following example shows the URL required to retrieve the WSDL for an Adabas "Employees" file.
| Server Name | SOAGateway |
| Port Number | 56000 |
| Name | adabas_Employees |
| URL for WSDL | http://SOAGateway:56000/adabas_Employees?WSDL |
The operations provided by the SOA Gateway for accessing data resources [ files, databases, programs, etc. ] are now explained.
Parameters are required unless otherwise stated.
| Operation |
list |
| Description |
The list operation returns a list of records or rows from your data source. The data returned can be limited or restricted by providing key information. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
select |
| Description |
The select operation returns a list of records or rows from your data source. The maximum number of rows/records returned can be set via the SOA Gateway Control Center. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL The data returned can be limited or restricted by providing key information. The select operation extends the capability of the list operation by enabling searches on a larger set of criteria. The key information for a select is wrapped in a condition block and can be repeated several times within that block. Each key entry represents an 'AND' condition. Condition blocks can also be repeated several times. Each condition block represents an 'OR' condition. The condition block accepts the following specifiers: |
| Conditions |
|
| Example |
<soapenv:Body> <cus:customerinformationGroupSelectElement> <condition> <CustomerNumber Condition="GE">40</CustomerNumber> <CustomerNumber Condition="LT">50</CustomerNumber> </condition> <condition> <CustomerNumber Condition="EQ">59</CustomerNumber> </condition> <condition> <CustomerNumber Condition="EQ">61</CustomerNumber> </condition> </cus:customerinformationGroupSelectElement> </soapenv:Body> The example above specifies 3 condition blocks. This will return data where the (CustomerNumber >= 40 and CustomerNumber <= 50) or CustomerNumber = 59 or CustomerNumber = 61 |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
selectNext |
| Description |
The selectNext operation returns a list of records or rows from your data source. A selectNext operation may only be called following a select and subsequently other selectNext calls. For this functionality the initial select operation has to initiate a new Conversation. See Conversational Processing. The resultant conversation id must be passed in any associated selectNext calls. selectNext calls may be issued until end of file is reached or may be terminated by a selectEnd call. The maximum number of rows/records will be that set for set via the Soa Gateway Control Center. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL There is no key information for a selectNext operation as this will have been passed in by the initiating select operation. |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
selectEnd |
| Description |
The selectEnd operation terminates a sequence of select and/or selectNext calls with a conversation. A selectEnd operation may only be called following select or selectNext operations. For this functionality the select operation has to initiate a new Conversation. The resultant conversation id must be passed in the selectEnd call. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL There is no key information for a selectEnd operation as this will have been passed by the initiating select operation. |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
selectCount |
| Description |
The selectCount operation returns a count of the records or rows that match the criteria set in the condition block(s). This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL The selectCount operation is identical to that of the select operation in terms of its search capabilities. The key information for a selectCount is wrapped in a condition block and can be repeated several times within that block. Each key entry represents an 'AND' condition. Condition blocks can also be repeated several times. Each condition block represents an 'OR' condition. The condition block accepts the following specifiers: |
| Conditions |
|
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
get |
| Description |
The get operation returns a single record or row from your data source. The data returned is specified by providing unique key information identifying a single record / row. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
add |
| Description |
The add operation adds a single record or row of data to your data source. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
update |
| Description |
The update operation updates a single record or row of data. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
delete |
| Description |
The delete operation deletes a single record or row of data from the data source. This operation will only be available when the web service is a "database" type, for example, Adabas or MySQL |
| Parameters |
|
| Result |
The result will be either :
|
| Operation |
invoke |
| Description |
The invoke operation makes a call to a function or program. This operation will only be available when the web service is a "program" type, for example, NATURAL, COBOL or when the web service describes a database stored procedure. |
| Parameters |
|
| Result |
The result will be either :
|
Keys or Key Fields in SOA Gateway terms are simply fields or columns on your data source (file, table, etc) that may be used to narrow a search for a record or row of data.
Note:
key fields may or may not be indexed at your data
source. Indexing provides better response times from your data source. If you
are unsure what, if any, fields are key fields (in Adabas terms: Descriptors)
or allowed to be used for searching, contact your data source administrator
(DBA, etc.).
Key fields are specified to the SOA Gateway by setting the appropriate value for the attribute "key type" in the Resource Description.
There are two types of key fields for data sources:
Primary Key Fields are fields in a data source that must always contain unique values.
They are required on all data source operations except the list operation, where they are optional. Secondary keys may be used instead or in addition on a list request.
Their values will not be altered in the update operation.
Primary Keys cannot contain wild card symbols, except on the list operation.
Secondary Key Fields are fields that may be used in narrowing a search.
They are not required in any operation, and their values can be updated.
They may contain wild card symbols.
Wild cards are used where you do not wish to specify an exact value in a key field, but use a generic specification that will match for a range of different values.
These search modifiers may only be used on the list operation.
The SOA Gateway currently supports the following generic search criteria :
The character "*" may be used as a wild card for all characters.
It may only be used on fields defined as "string" fields.
Where it appears, it will match any character or group of characters.
Note:
for Adabas resources, this wildcard may only appear at the
end of the string data supplied.
"Ga*" would match "Gat", "Gate", "Gateway", etc.
In the SOA Gateway, the SOAP Headers are used for versioning, the support of conversational SOAP processing, support of transactions, and specific settings on the datasource you are accessing. By default all elements are "empty". To get the default behaviour, all header elements should be left blank, or removed altogether. Example:
<soap:Envelope xmlns:rapdv="http://www.risaris.com/namespaces/xmiddle" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<rapdv:AdabasEmployeeHeader>
<Version/>
<ConversationState/>
<ConversationId/>
<TransactionState/>
<TransactionId/>
</rapdv:AdabasEmployeeHeader>
</soap:Header>
<soap:Body>
...
</soap:Body>
</soap:Envelope>
Every time a SOAP request is made to the SOA Gateway, this request must be associated with a specific context. By default, a new context is created and destroyed for every SOAP Request.
The user may also use the SOAP Headers to re-use and re-connect to a specific context.
When a user starts, re-uses, and ultimately finishes with their context, the process is known as a "conversation". In the SOAP Header, the "ConversationState" and "ConversationId" are used for conversational processing, see below for more information.
The 'Version' element is currently unused. It will be brought into use in future versions of the SOA Gateway.
The 'ConversationState' element is used to control conversation processing. It should be one of the following:
| State | Description |
|---|---|
| New |
A new conversation is being started. In this case, the ConversationID ( see below) value must by NULL or an error will occur. |
| Old |
An existing conversation is active with which the current SOAP message should be associated. When the SOAP request is processed, the conversation must remain active as there are further SOAP requests to be sent. The ConversationID found must have been returned as a result of a previous 'new' request. An error will occur if the ConversationId ( see below ) provided cannot be found. |
| End |
An existing conversation is active with which the current SOAP message should be associated. When the SOAP request is processed, the conversation must be terminated. The ConversationID ( see below ) found must have been returned as a result of a previous 'new' request. An error will occur if the ConversationId provided cannot be found. |
The ConversationId unquely identifies the conversation, and it returned only after a 'New' request is successfully processed. The user should never modify or create this ID. The ConversationId must be present on an 'Old' or 'End' request.
In the SOA Gateway, the platform's Transaction Manager (TM) will be engaged to handle transactions. A default TM is provided as part of the ASG installation. It can be found in <asg install dir>/libraries/transactionManagerDummyDll.so. The environment variable TMSTUB is used to point to the transaction manager shared object. This shared object provides interfaces to handle the transaction.
Note:
The framework for engaging transaction managers is subject to
change. Currently the transactionManagerDummyDll.so does not provide any "real"
transactionality. Rísarís are current looking for early adopters to work with
us to fully implement and test this technology.
In the SOAP Header, the "TransactionState" and "TransactionId" are used for transactional processing; see the table below for more information.
If a transaction involves modifications that will occur over multiple SOAP messages, the conversational processing logic must be used to associate the SOAP messages and thus the transactional information.
If a transaction involves modifications that will all be completed as part of the one SOAP message, the conversational processing logic is not required.
The Transaction State may be one of the following:
| State | Description |
|---|---|
| New |
A new transaction is being started. If no conversation will exist after this request, an error will result. If the request is part of an existing conversation, and this conversation already has a transaction associated with it, this will also be rejected as an error. |
| Old |
An existing transaction is active with which the current SOAP message should be associated. If no conversation exists for the SOAP request, or no conversation will exist after the SOAP request, an error will result. If no transaction is active and associated with the current conversation, an error will result. |
| Commit |
This will cause a commit to be issued when the current SOAP message has been processed. If no conversation existed previously for this SOAP request, a new transaction will be started. If a conversation does exist for this SOAP request, any updates made as a result of the previous SOAP requests will be committed. When returned in the SOAP response, it indicates that the transaction has been committed. |
| Backout |
This will cause a backout to be issued when the current SOAP message has been processed. If a conversation does exist for this SOAP request, any updates made as a result of the previous SOAP requests will be backed out. If no conversation existed previously for this SOAP request, an error will result. When returned in the SOAP response, it indicates that the transaction has been backed out. |
The Transaction ID is purely informational, and has no functional bearing on the transaction process. It is returned on any SOAP message and is intended to be used for tracking purposes.
When working with Adabas services, there are a number of specific SOAP headers that will be available
| SOAGateway_Internal_Adabas_ISN |
On a GET operation an ISN (Adabas Internal Sequence Number) can be used in lieu of a primary key to retrieve a record. |
| SOAGateway_Internal_Adabas_StartAtISN |
In addition to the specification of key data this header option can be used to further limit the result set by setting a starting ISN for LIST and SELECT operations. |
| SOAGateway_Internal_Adabas_Read_Direction |
Specify an "A" (the default) for ascending retrieval, a "D" for descending. |
| SOAGateway_Internal_Adabas_Sort_Order |
The result set can be sorted by up to three fields. Specify their XML names, comma separated, with this header option |
| SOAGateway_Internal_Adabas_Password |
The password required to access an Adabas file secured with ADASCR (Adabas Security). This password is different from that in the global "soap security" section. |
| SOAGateway_Internal_Adabas_Multifetch_Limit |
Limit the number of records to be retrieved by a "multifetched" operation (LIST or SELECT / SELECTNEXT) with a single call to Adabas. |
When working with relational database services, i.e. MySQL, MS SQL Server, DB2, Oracle, etc, the specific SOAP Header are
| SOAGateway_Internal_AutoCommit | Turn off the AutoCommit flag on the database |