Invoking Web services by using an automatically generated self-defined operation
This section describes how to use the Web services self-defined operation feature that is included in UNICOM® Digital Transformation Toolkit (UDTT™). The Web services self-defined operation feature automatically generates the self-defined operation that is required to invoke the Web services that you want to use.
Prerequisite
If you are retrieving the WSDL file from UNICOM Service Registry and Repository (WSRR), you must first specify the WSRR host address and port number in IBM Rational Application Developer. See WebSphere Service Registry and Repository.
The Web services self-defined operation feature automatically generates the self-defined operation that is required to invoke the Web services that you want to use. Using the Web services self-defined operation feature means that you do not have to manually generate the data and the context for a self-defined operation. The Web services self-defined operation feature also automatically creates data mappings between the data elements belonging to the UDTT operation context and the data elements belonging to the Web services.
Procedure
1 Launch the New Web Services Connector wizard through the toolkit project in which you want to store the definition files and the Java classes of the Web services connector.
▪ Right-click the toolkit project in which you want to store the definition files and the Java classes for the Web services connector.
2 In this wizard, you can either select the WSDL file of the web services from a URL or from the workspace, if the web service was previously created in the development environment by the technical developers or the WSDL files for remote web services have been imported into the workspace as part of the environment configuration. In both cases the technical developers should tell you where the WSDL file is located.
The following fig shows how to input WSDL location from Workspace. When finished, press OK and move to the next step.
3 Click Next.
The Generate Web Services Client wizard opens.
4 Select the UDTT Project folder in which the operation implementation class will be created and the Target package, meaning the WSDL namespace to package mapping. You can keep this field blank and then the default mapping will be used. For the other fields, you can also keep the default values.
5 Click Next. The Service information wizard opens.
Two attributes are especially important in this wizard: the web service connector (WSConnector) and the Endpoint address.
▪ web service connector (WSConnector): The toolkit provides a default WS connector that registers the handlers that add to the web service messages the architecture and security headers: com.ibm.btt.services.ws.javax.BTTJaxWsHeaderConnector. This connector is selected by default.
▪ EndPoint address: Select the address of the web service function you want to generate the operation for. The URL in which the web service is published depending on the different application deployment environments. Your development environment can be configured by the technical developers so that a variable represents the web services server location. The variable for target web services server is resolved to a real URL address during runtime. See below an example of such a variable, esbHost.
6 Click Next. The Derive Self-defined Operations panel opens. The default implementation class for all automatically generated web service access operation is com.ibm.btt.base.ws.WSAccessOp (a different implementation may be provided by the technical developers and would be specified). Check from the Operation List table, all the web service calls for which you want to generate an operation.
Note Several methods are listed as possible web service access calls if the web service does provide different functions. For each of the listed methods, an operation will be created for corresponding to a function provided by a web service and in each case the operation data would be automatically mapped to the request and response web service corresponding function data.
You can select the option Data will be generated with UDTT type.
▪ If the option is selected, the tooling verifies for each web service request and response data if there is a defined UDTT type matching the web service data type and uses it to define the new operation data. The configuration file defining the type mapping between WSDL types and UDTT types must be available to enable this option. For more information about default type mapping, see Default type mapping.
▪ If the option is not selected or the corresponding UDTT type is not found, the generated UDTT data will be one of the default types. For instance, for a complex business object with several attributes, if the type does not exist in UDTT, a keyed collection labeled with the business object name and with as many fields as business object attributes is created. The WSDL to UDTT type mapping configuration file can also be used to define which XSD type matches with which UDTT type (different names) and to map XSD type restrictions to UDTT type parameters. For more information about customizing type mapping, see Customized type mapping.
You can also select the option Data will refer to global dictionary.
▪ If the option is selected, the tooling verifies for each element in the web service definition if there is already a defined UDTT data in the data dictionary matching id, type and structure (field or data) and then, instead of creating a new data element, the wizard will create a reference to the existing data. For detailed rules, see Default dataname mapping rule. The name mapping default behavior can be changed by using an extension point; see Providing ID Mapping During SDO Generation.
▪ If this option is not checked, for all elements defined by the web service new UDTT data elements will be created locally in the newly generated self-defined operation.
When adding a reference to an existing data, also the restrictions defined in the WSDL may be added as refData params if they do not match the values of the properties defined for the referred data. In this case, the refData param values will override the referred data values. If the properties values match, then no param child will be added to the refData definition.
