In order to interpret an XML response from a REST web service, Blueriq needs to import an XSD. In contrast to SOAP, there may not be an explicit contract available for REST (WADL). You can use the api of the REST service to get xsd files. If the REST service only gives example answers, you can automatically generate an XSD file from the examples. (http://www.freeformatter.com/xsd-generator.html#ad-outputhtml)

Go to File → Import → Import XSD and provide the location of the XSD file. If you have multiple files (for example: your XSD is importing/including an XSD schema) then provide a zip file with all needed files. This is essentially the same as importing a WSDL (Chapter 4: Calling a SOAP service) Select the project for the import and you can choose whether to create a new module, or overwrite an existing one. When overwriting, as much as possible from the old module is kept. You can choose whether you also want to create a domain model. The option 'Generate Domain' will automatically generate domain for you, based on the XSD schema referred to from the WSDL. When this button is checked, entities, attributes and relations are created based on the type definitions of the XSD. When using an existing module, there may already be a domain present, that uses identical names as in the XSD. When overwriting, conflicting elements are not created. Obviously, these problems do not occur if you use a new module. When 'Generate Domain' is unchecked, no domain is generated for you. In that case, you can later match the elements from the XSD to you own domain (explained later). In general, it is advised to use a separate module in order to not mix the domain for the web service with the domain of your business.

Image AddedImage Removed

You should get the message that the import was successful.

Open your project and go the (newly-created) module which contains the webserviceweb service. The module now has a Schema Set. This item can be found in the bar on the left side of the screen, as can be seen below.

Image RemovedImage Added

The Schema Set defines which entities, attributes and relations are used by the webservice web service (they map the XSD to the domain model). If the domain model was created automatically, then you can skip the following step, and directly go to Creating a Service Call.

Open the Schema Set, and unfold the schema. You can choose which entity is mapped to this type in XSD schema, as can be seen below. In this case, the anonymous complex type of the element “add” in the XSD schema is mapped to the entity “add” in the domain model (the red box).

Image Removed

When choosing simple elements, you can choose to which attributes they map. See below. Mapping relations works in a similar way.

Image Removed

For each operation, the webservice needs two singleton entities: a Request entity and a Response entity, which will be used to create the message. When you create the domain automatically, you will find these along with the other entities of the domain. You can use the soap service editor to create mappings for these, if you did not create the domain automatically, see below:

Image Removed

This works exactly the same for REST and SOAP, and the description can be found here: Chapter 4: Calling a SOAP service.

In contrast to importing a WSDL, no service definition is automatically generated, You have to define how the REST service is called manually. Create a new REST service object and give your REST service a name, see below:

Image Removed

.

Next, you need to specify the location of the REST service. This is an URIan URL. You can already specify fragments and arguments here, but then you cannot change them later. For example, check http://services.faa.gov/airport/status/IAD?format=xml. In this case, airport, status and IAD are dynamic fragments and can change, depending on input by the user. You would only use http://services.faa.gov/ as location in this case.

Now specify the Schema Set that you want to use. Choose the Schema Set that you have imported earlier.

Image RemovedImage Added

You can specify as many operations as you need, by pressing on the plus icon. Give every operation a unique name.

Image AddedImage Removed

Request

If you want to dynamically change the address or send custom headers or body in your message, you need to specify a singleton entity from where the information is gathered (1). (2) shows the URL you are going to call. Items within {} are dynamic and determined during runtime. You can add static fragments (3) which are always the same, or dynamic fragments (4) which are filled by attributes of the request entity. You can specify arguments (5) of your request the same way.Image Removed

Image Added

You can also send a message to the REST web service as part of the http headers. This procedure is the same as for the response of the message that you find just below here.

Response

Now you can specify how your message looks like. (1) lets you specify what kind of message it is (Get, Post, Put or Delete). If you need to set headers, then you can do so at (2) in the same way you set arguments or fragments earlier. If you need to send information in the body of the message, for example with a Post message, then you can specify this now. This is done in XML, and your Schema needs to be able to handle this. If you have a SimpleType in the schema, then you fill in an attribute at (5). If it is a complexType, then first choose which entity will be send at (3) and then you attribute field (5) will swithc to a relation field. Fill in the name of the relation between your singleton request entity and your data entity. Custom Schema Elements (4) are ways to fill in your schema in a different way other than with data from your profile. It is not needed at the moment.

Now you need to define how you receive data from the REST service. Click on response and you will see a window just like the window in the screenshot above. Fill in the form the same way as explained above.