You can turn an external web-service interface definition into classes in your MDriven model so that you can work with the service's XML or JSON-shaped data using the model; this is for developers integrating data from SOAP or REST services.
What this workflow does
An interface definition such as an XSD or WSDL describes the structure of data exchanged with a web service. Importing that structure as model classes gives you a starting point for representing messages and data in MDriven Designer.
For example, a service may return a stock quote with fields such as Symbol, Last, and Date. A cleaned imported model can contain corresponding classes and attributes that describe that data.
This workflow imports the data structure into the model. It does not, by itself, configure a call to the external service:
- To call a SOAP service from a ViewModel, use SOAP from MDriven and selfVM.SoapCall.
- For REST-service scenarios, MDriven supports calling external REST services and exposing ViewModels as REST data sources. See REST services in MDriven|the REST services walkthrough.
- To expose data from an MDrivenServer through its available interfaces, see MDriven Server User/Web interface.
Supported import path
MDriven Designer cannot import an XSD or WSDL directly. Use Sparx to import the schema and export it as XMI, then import that XMI into MDriven Designer.
| Input or format | Use in this workflow |
|---|---|
| XSD | Import into Sparx first. Do not attempt to import it directly into MDriven Designer. |
| WSDL | Import into Sparx first. Do not attempt to import it directly into MDriven Designer. |
| XMI 2.4.2 | The required XMI version for import into MDriven Designer. |
| UML 2.4.1 XML export | Select this UML version when exporting the cleaned Sparx model. |
Important: MDriven supports only XMI 2.4.2 for this process. An XMI export in another version is not a supported import input.
Import an interface definition as a model
- Obtain the XSD or WSDL that describes the external service.
- Import the schema into Sparx.
- Review the imported Sparx model before exporting it. Schema imports commonly contain both classes and UML elements that are not useful as domain-model classes in MDriven Designer.
- Remove the imported elements that you do not need, while keeping the classes that describe the data you intend to use.
- Check the retained classes and their attributes against the message structure you expect to receive. For example, if the response contains a
Stockitem withSymbolandLast, retain the class and the attributes needed to represent those values. - Export the cleaned model from Sparx as XML, using UML 2.4.1 and XMI 2.4.2.
- Import the resulting XMI 2.4.2 file into MDriven Designer.
- Review the imported classes in MDriven Designer and adapt the model to the part of the interface that your application uses.
Clean up before export
Cleaning the Sparx model before export keeps the imported MDriven model focused on the data you need. Retain classes that represent useful request or response data, and remove imported elements that do not contribute to that model.
For example, if an imported service definition produces many schema artifacts but your integration only reads a quote response, keep the classes required for the quote response and remove unrelated elements before the XMI export. This makes the imported model easier to understand and maintain.
Do not treat the generated model as a complete integration. You still need to design how your application calls the service, receives its response, and maps or cleans returned values. A SOAP response can require additional cleanup before its inner data can be used; the SOAP example shows a response where the relevant XML is returned HTML-encoded inside a result element. See SOAP the protocol from the stone age.
Validate the result
After importing the XMI into MDriven Designer, validate the model before building application logic:
- Confirm that the expected classes were imported.
- Confirm that the attributes needed by the request or response are present.
- Remove or revise structures that are not needed by your application.
- Use the cleaned model together with a ViewModel and the appropriate integration logic.
For SOAP calls, selfVM.SoapCall takes its parameters from a named ViewModel nesting. The nesting must represent the arguments expected by the service operation. See OCLOperators SoapCall for the operator syntax and the SOAP guide for a worked example.
Related import tasks
This page concerns importing an external interface definition as model structure. It is different from importing data rows into existing model objects. For tabular data imports and association setup, see Import Data, Import Tabular Separated Data Using OCLOperators, and SQLImport multiple tables with associations.