Online documentation - Websydian v6.5 |
The WSDL import tool is used to model the XML structures used to connect to a web service. The most common structures are naturally the documents used as input and output when calling the service. But the WSDL can also describe other structures, such as fault and header structures.
So the WSDL import is basically an extension of the W3C schema import - with added functionality to parse the WSDL and extract the schema definitions contained in the WSDL.
Run the WSDLImportGUI.exe file to import a WSDL file. The following panel will be shown:
Specify the location of the file containing the W3C schema in the input field "WSDL file".
You can either specify a file location or a URL specifying the location of the file on a webserver.
If you use the Browse button to select the file, the WSDL is automatically parsed.
Press the "Process" button to parse the WSDL if you have not used the Browse button to select the file.
In some cases, the WSDL import must extract a schema file from the WSDL and save it to a file to be able to load it correctly for the schema import.
You can specify where the tool must save these temporary file in the setting "Folder for temporary files".
Shows basic information about the tool - it also provides a link to the current version of the documentation.
When the WSDL has been parsed, the structure is shown as a treestructure.
The topnodes (E.g. WebsydianDemo) correlates to a URL (hover the mouse over the servicename to show the URL).
The childnodes are the operations you can access for this service. These operations correlates to SOAPActions (hover the mouse over the operationname to show the SoapAction).
By pressing the "+" shown for the operations, you can see the messages used by each operation:
Each operation can use the following messages:
In most cases, only input, output and possibly fault will occur.
You must import each message in a separate step. You start the import simply by double-clicking the message.
This launches the schema import for the schema definitions referred by the WSDL message.
This panel shows the name of the topelement that will be imported (Element to import as...). This will become the name of the top XMLElement entity created in Plex.
The "Save file to" field is defaulted to the folder that has been specified as the one where the temporary files must be placed and the filename pleximport.xml.
If you want to specify another folder/file you can do so.
If you leave the "Create Limits All triples" checkbox checked, each field created by the schema import will have a FLD limits all triple. If you uncheck the checkbox, no limits triples will be assigned to the field.
If you keep the "Use inheritance specific for input messages" checkbox checked, the inheritance is defined for each message type (one set of settings is stored for input, another for output, etc.). When the checkbox is checked, the grid shown when the "Inheritance" button is pressed will be populated for the specific message type - and if you choose to save these settings, they will also only be used for the specific messagetype (see more below).
Press the "Generate" button to create the Plex import file.
In some cases you might want to specify inheritance specific to each messagetypes.
For example if you are going to call a web service, you will normally only create the input documents - and only read the output documents.
By creating your own abstract entities MyXMLElementInput, MyXMLRepeatingElementInput , MyXMLElementOutput, and MyXMLRepeatingElementOutput in your Plex model, you can control which of the functions scoped by the XMLElement entity to generate and build.
For MyXMLElementInput and MyXMLRepeatingElementInput, you can for instance set GetFirstOccurrence and SingleFetch to implement No, as you are not going to read these documents.
For MyXMLElementOutput and MyXMLRepeatingElementOutput, you can for instance set InsertRow and InsertRowDanging to implement No, as you are not going to create these documents.
When you work with large/complex documents, this can save quite a lot of generation/build time.
To make the import use these new abstract entities, do the following:
When importing the first input message you are going to handle - open the inheritance grid on the schema import panel and change the values as shown below:
After changing the settings, press "Save Settings". This means that all the entities created for the input messages will have this inheritance (as long as the "Use specific inheritance for input messages" are checked).
Do the same when importing the first output message.
In the example, I have only mentioned input and output, you can of course do the same for the other messagetypes (fault, input header, input header fault, output header, output header fault).
If you do not want to use specific inheritance for each message type, but still want to use your own abstract Plex objects, just uncheck the "Use inheritance for..." checkbox and specify the inheritance in the grid - remember to press "Save Settings". As long as the checkbox is unchecked, the import will use these settings.
The limitations described for the schema import are also valid for the WSDL import.
The import only supports WSDL 1.1.
The WSDL standard defines the possiblity to import other wsdl files using a import element belonging to the wsdl namespace
(http://schemas.xmlsoap.org/wsdl/). This is not supported by the tool.
Please note that the import statement in the schema namespace (http://www.w3.org/2001/XMLSchema) is supported. Basically, this means that import elements found inside a <schema>...</schema> element will be handled - while import elements found outside the schemas will not be handled.
The tool only supports the SOAP 1.1 binding.
If other bindings (e.g. HTTP, SOAP 1.2) are used in the WSDL, the operations will not be shown in the treestructure.
The tool only supports http as transport.
If any other transport is specified, the operations will not be shown in the treestructure.
The import only supports document/literal messages.
If the WSDL describes operations/messages that is not document/literal, they will not be shown in the treestructure.
The tool only supports import of types using the W3C schema format.
The WSDL standard contains certain unclear points. There are even some cases where the textual descriptions and the schemas describing the WSDL format are different. In the cases where these inconsistencies have relevance for this tool, we have followed the clarifications made in the WS-I Basic Profile.