This chapter describes how you can setup Blueriq, so that it exposes itself as a web service. This means that other parties are able to call Blueriq and that Blueriq will formulate an answer. You can both use Blueriq as a SOAP and REST service. What type exactly does not matter for most steps this chapter.
You start with the same steps that you would take when you would call a web service. This means that you have to import a WSDL for SOAP or import an XSD or define a Domain schema for REST. These steps are described in 4. Calling a SOAP service and in 5. Calling a REST service. The main difference is that everything you define is for your own web service. This means that the WSDL you import will be yours, you are able to define it yourself. (For more information on this, see Appendix 1 - Writing your own WSDL). For REST, the Domain schema or all the imported XSD and defined fragments and arguments will be for your own web service. The main conceptual difference when using the REST service editor is that the request message now defines the message that you receive, and the response message is the message that you are sending as a response to the other party. This is exactly the opposite manner compared to when you call an external web service.
When calling an external REST service, you can place the status header in an attribute, which holds the status code of a the response. For BAARS, this is not an output parameter but an input parameter, and you can set the status code of the response yourself. A good use of this functionality is for instance to set status code 201 when you created a new entry in the system (for example when the AQ_Aggregate_Create service was used)
After you are done, it is time to expose your webservice. For this you need a configuration module. In this configuration module, create a new web service.
Give your service a name (1) and select the module in which the web service is located (2). Now at (3) you choose what kind and which service you want to expose. At (4) you can specify whether the webservice should validate the message. Close the 'General' menu and you will see a screen like this:
You have to press the 
icon to expose the method to the outside world. Every method for which you do not press this button is not exposed, and cannot be called.
After exposing a method, you get the following screen:
On the left you choose what method you want to expose. These are methods defined in your WSDL or your REST service. You can optionally specify extra options for your web service. At (1) you can specify a data mapping, which is located in the same configuration module. If your web service is located in a different module than your business logic, you need to make a data mapping between the two modules.
Attention: the module with the business logic needs to be set as entry point in this case!
At (2) you can specify a flow which willexecutedwhen your web service is called. For example, in thisflowyou can use other external sources or even call a different web service. There are no pages allowed in this flow.
At (3) you can specify roles that a user should have.
Save, and your web service is ready to use. Go to the runtime and reload your project. Go to 'Widgets' and activate the 'Expose as awebservice' widget.
You will get the additional window (SOAP on the left, REST on the right)
Select your project and choose the web service. If you expose a SOAP service, then you can view the WSDL of your SOAP Service, in which the correct URL location can be found.
Now you can call your web service, for example using SoapUI.
If you exposed a REST service, then the REST service URL will be shown. You can test your service by pasting this URL in your browser.
In case that you checked the Validate checkbox from the service definition, then the created Validation rules are taken into consideration. These validations can be per Attribute or per the entire request.
For example, let's say that there are 2 Attributes in the request: Request.Attribute1 and Request.Attribute2 with the following Validation rules:
- A Validation rule which validates that Request.Attribute1 has a value between 1 and 5
- Another Validation rule which validates that Request.Attribute2 is greater than Request.Attribute1
When the request is made having Request.Attribute1 = 3 and Request.Attribute2 = 2, the first validation rule is true but the second validation is violated and in the Response, an error message will be returned having the validation message stated.
Shortcuts
It is possible to create a shortcut for yourwebserviceso that location URL is shorter and hides details such as the branch. This also gives you the flexibility to change the application that the shortcut is pointing to without the need to change the URL in calling systems.
In the runtimedasbhaord, go to Settings -> General -> Shortcuts. Press the add button, and create a shortcut to yourwebservice. There is no need to select a flow, and other settings such as User Interface or Theme are also not important now.
Such a shortcuts lookslike this in the application.properties:
blueriq.shortcut.ShortcutName.flow= blueriq.shortcut.ShortcutName.languageCode=en-GB blueriq.shortcut.ShortcutName.project=studio-Web_Calculator-WebCalculatorAAAS blueriq.shortcut.ShortcutName.theme=blueriq blueriq.shortcut.ShortcutName.ui=xslt blueriq.shortcut.ShortcutName.version=0.0-Trunk
Now you can select the shortcut in the 'Expose as a Webservice' widget on the runtime dashboard, and view the new WSDL. You will see that the location of yourwebservicewas changed and now uses the shortcut.
Swagger feed for REST services
A Swagger feed of REST services is provided by the Runtime, see Swagger for more information.
Knowledge Base Articles
| Title | Creator | Modified |
|---|---|---|
| Web Services guide | Unknown User (m.schadd) | Jan 22, 2024 |
Previous: 5. Calling a REST service
Overview
Content Tools