Ispec Field Usage
The Ispec Field Usage specification is used to determine how to generate the input and output message for a Web Service. However, the Field Usage only specifies in an unambiguous way which fields are input to an Ispec. Based on the Field Usage it is not possible to automatically determine which fields are sent back from an Ispec. Often this is decided in the logic of an Ispec at run time.
The interpretation of the Field Usage for output purpose can be specified in the GeneratorConfig.xml file. The following table shows the rules for how the Field Usage is interpreted. The “Web Service Output” column shows the default interpretation when nothing is specified in the XML file.
The Field Usage of Data Items which are defined as usage default, is as defined for the underlying Ispec.
Component Type | Ispec Field Usage | Web Service Input | Web Service Output |
---|---|---|---|
Memo Component | I/O, Ordinate | n/a | n/a |
Input | Yes | Yes | |
I/O | Yes | Yes | |
Inquiry | No | Yes | |
Input Not Enterable | No | n/a | |
I/O Not Enterable | No | n/a | |
Output | n/a | n/a | |
Standard Component Maint=INQ and REC | I/O, Ordinate | Yes | n/a |
Input | No | Yes | |
I/O | No | Yes | |
Inquiry | No | Yes | |
Input Not Enterable | No | n/a | |
I/O Not Enterable | No | n/a | |
Output | n/a | n/a | |
Standard Component Maint=NEX and BAC | I/O, Ordinate | Yes | Yes |
Input | No | Yes | |
I/O | No | Yes | |
Inquiry | No | Yes | |
Input Not Enterable | No | n/a | |
I/O Not Enterable | No | n/a | |
Output | n/a | n/a | |
Standard Component Maint=CHG and ADD Note: No fields is passed back. Only the Status-Line is passed back. | I/O, Ordinate | Yes | n/a |
Input | Yes | n/a | |
I/O | Yes | n/a | |
Inquiry | No | n/a | |
Input Not Enterable | No | n/a | |
I/O Not Enterable | No | n/a | |
Output | n/a | n/a | |
Standard Component Maint=DEL and PUR Note: No fields is passed back. Only the Status-Line is passed back. | I/O, Ordinate | Yes | n/a |
Input | No | n/a | |
I/O | No | n/a | |
Inquiry | No | n/a | |
Input Not Enterable | No | n/a | |
I/O Not Enterable | No | n/a | |
Output | n/a | n/a | |
Standard Component Maint=FIR and LAS | I/O, Ordinate | No | Yes |
Input | No | Yes | |
I/O | No | Yes | |
Inquiry | No | Yes | |
Input Not Enterable | No | n/a | |
I/O Not Enterable | No | n/a | |
Output | n/a | n/a |
Standard Components and AutoMaint Memo Components
A Dotnet Web Service method is generated for each of the MAINT functions for Standard Components. Using options specified in the GeneratorConfig.xml file, you can choose which MAINT functions to generate. By default, no functions are generated. The MAINT field itself isnot exposed as a Web Service. Depending on the method being requested, the MAINT field is completed in the GeneratorConfig.xml file with a corresponding value before calling the Ispec. The method names are generated as the Ispec name, suffixed by the full name of the MAINT function, for example, <Ispec-name>_Inquiry.
The full names of the MAINT functions are listed in the following table:
Abbreviated Name | Full Name |
---|---|
INQ | Inquiry |
REC | Recall |
NEX | Next |
BAC | Back |
CHG | Change |
ADD | Add |
DEL | Delete |
PUR | Purge |
FIR | First |
LAS | Last |
Memo Components
It is strongly recommended that you use Memo Components for Dotnet Web Services. You are benefited the most from the Dotnet Web Services technology if you write new
Ispecs, or where feasible, modify existing Ispecs for use as Dotnet Web Services. The Dotnet Web Services technology is a different paradigm to traditional Agile Business Suite systems and there is no easy mapping between the two. What needs to be considered is that the definitions/specifications of an application that are available to the Dotnet Web Services Generator at the time of generating the services do not describe what actually happens at run time when running the application. In some cases, users of the Dotnet Web Services Generator benefits from tailoring the generated ASP Web Service and WSDL to match the exact requirements of the application.
Other Components
Components other than Memo and Standard Components are generated following the rules specified for Memo components. It is not recommended that you deploy other than Memo Components as Dotnet Web Services. It is the responsibility of the developer to decide whether an Ispec is appropriate for deploying as a Dotnet Web Service.
Ispec names and Data names
To generate meaningful Dotnet Web Service method names and XML tag names in the WSDL file, the generator can optionally use the Ispec description and data descriptions as follows:
An option in the GeneratorConfig.xml file specifies whether to use the descriptions for Ispecs and Data items or to use the short names. The default is to use descriptions.
When using descriptions the following applies:
Spaces, less than signs, and greater than signs are replaced by the underline character (_). This is to support the XML encoding.
As description items are not validated in Developer, you should ensure that descriptions are unique and support the XML encoding. The Dotnet Web Services Generator verifies that descriptions are unique. To create unique names, the Dotnet Web Services Generator appends a number at the end of duplicated names and a warning is written to a log file. The log file is saved in the same directory as the generated ASP and WSDL files. The name of the log file is bundle_name.log.
Short names are used when the description for a Data Item or an Ispec is blank (that is, not specified).
Input Ispec same as Output Ispec
The Dotnet Web Services Generator assumes the input Ispec is the same as the output Ispec. The code generated by the Dotnet Web Services Generator returns to the client an error at run time, when an Ispec at run time does a recall and returns a different Ispec. The reason for this is to comply with the purpose of the WSDL file, which is to let the client developer know what to expect from the Web Service.
The WSDL file should contain all the information required to develop the client application. This information includes a description of the required input parameters and a description of expected output parameters. As the Dotnet Web Services Generator does not have any knowledge of what happens inside the Ispecs at run time, it assumes the input Ispec is the same as the output Ispec.
Stateless Systems
The generated Web Service assumes a stateless environment. The SOAP standard does not provide support for state full or conversational interactions.
Status Line and other system specific fields
The Agile Business Suite status field is always returned. The status field is generated in the WSDL file at the end of each response message part, as an element occurring one or more times. At run time, the status-line is moved to the Web Service response message. When an Ispec returns multiple errors, they are moved to occurring elements of the status field.
Other system-specific fields, such as the MAINT field and ACTMTH field, are not returned in the Web Service response message.