Home | Printable Version
3.2: SOAP Services
The Import Service wizard examines selected WSDL files and generates controllers that can be used to call the defined web service. Web Service Proxy controllers are created, containing the location information (URL) for remote services, and Access Service controllers are also created, containing rules to ensure correct messages are sent to and received from the external web services. Other controllers can then use the generated Access Service controllers to interact with the remote web services. As well as the explicit Import Service wizard, remote service proxy controllers and access service controllers are also generated when pages are designed using WSDLs as a data source within the Page Design tab. Screen shot of the Project Settings screen The Import Service wizard can also be accessed to process WSDL files, to generate the various server controllers, without having to design pages first. You can use the Advanced Project Settings menu option and scroll to the bottom of the Project screen. Clicking the Import Service button will show the following screen: Screen shot of the WSDL import screen Select the WSDL file that defines the service you want to use. You can use the Repository Viewer to open a local file or use the Upload From URL tab to load the WSDL from its web location directly. After you have selected your WSDL file, you can click Next to perform the import process. This should parse and validate the selected WSDL file and generate the required controllers. Once completed, you should see a success message, and a link to return to the Project Screen, which will now show two entries for the generated runtime patterns in your chosen layer. Note: WebMaker requires valid WSDL files, based on the WSI industry standards. If a WSDL file fails to parse, a list of errors will be provided. If a selected WSDL file was parsed previously, or there are unforeseen name conflicts, then WebMaker will prompt you for a Name Prefix to ensure the names allocated for the generated controllers will not conflict with others in the repository. Once the access service controllers have been created, other controllers can use them. Generally, this will happen automatically where needed, but can be done manually by adding rules from the relevant Controller. You would need to add a rule with an Invoke Service Action, and then use the Service Call Helper option to select the newly created Access Service.
Proxy Service Generation
The image below shows the default set of rules that are generated when a WSDL is imported. The import process generates two controllers, one called the Access Service and other known as the Proxy Service. The two controllers are often collectively referred to as the Proxy Service. The proxy controller simply acts as the placeholder for the URL of the remote service and contains no structure or content. The Access Service contains the rules shown on the image below. Access Service Rules calling Proxy The first rule applies the SOAP Wrapper (Envelope and Body) required for a SOAP Service. This is then followed by a rule for each remote service operation, which will check to see if the factbase has the correct message content before calling the particular service operation endpoint. Towards the bottom of the rules, there should be three further rules generated by default. The first one handles the soap Fault fragment if it is returned from the service, the second one handles a soap response with no Soap Header fragment and the third rule handles a soap response that contains a Soap Header fragment. If a Soap Header is returned the Access Service rules will return the whole Soap Envelope back to the Controller, otherwise it will return the contents of the Soap Body only. You can change these rules as required.
Automatic Data Binding REST Services