Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Your new module typically has no pages for user interaction, and even a flow is not always needed. If you create a flow at all, it will just contain service calls to create instances and/or set attribute values and/or relations. In other words, to create all that is necessary to fill the response. 

 

 

If you want to just see a working example of of , you could use the standard example project WebCalculator as a basis for your new project (see the visual SoapUI to example project BAAS). However, if you want a more hands-on experience and construct that BAAS yourself, this is what you could do:

Start with an empty new project, and import the WSDL from the WebCalculator example to fill your interaction module with the service model (i.e. a domain model specifically for delivering the service), the Schema set and the SOAP service as defined in the WSDL and XSD. Your service will perform the calculation for which it receives a request with corresponding input parameters, and therefore In this visual, there is no flow at all. There are static instances prepared for the response, and the calculations are simply done in the default expressions of the output attributes. 

Note

 

Because there are no pages, no instances will be created automatically for you, not even the singletons! The only instances that will be present when the service is called, are the instances of the incoming request. In this case, one instance for Request and one for Request_1.

That is why you have to create all response instances in a flow, or use static instances.

When your Interaction module is ready to handle incoming requests, you still need a way to tell the world which operations you are offering: Close your project, edit your project structure and add a Configuration module. Open your project again, go to the new Configuration module and create the Web service. Let it refer to the SOAP service in the interaction module to see its operations. You must give properties to each operation that you want to expose, even if you don't refer to a data mapping or a flow. This defines what you expose to the outside world in your runtime dashboard. In this example, the exposed operations are add, subtract, multiply and divide.

You can test if the BaaS works by calling it from SoapUI, a web services testing tool (it can mock both requests and responses) that is easy to download and install. In SoapUI, you can create a new project. You will need the URL to your service. To get this URL, go to runtime dashboard, reload your web service project, and expose it as a web service. Now click ‘view WSDL’, copy the URL from the browser tab and paste it into your SoapUI project as “Initial WSDL”. Then create a request for the add operation, fill in x and y, and check if the response delivers the desired result.

The consequence of separating the web service (interface) module and the interaction (business) module is that you will need a data mapping between the two modules. Now that your BAAS is the service provider, the data mapping is the other way around as when you are the service requestor: Now the web service interface model is the source model, and the business model becomes the target model. Consequently, the forward mapping now translates the incoming request into understandable data for your business model, and the backward mapping transforms the resulting business data into a response that adheres to the interface contract. See also How to do a mapping.

When you have the data mapping in place (and used by the Web service!), you can test if the BaaS works by calling it from SoapUI, as described in the visual Call to BAAS.