Getting Started

Adapter configuration and call within the platform

Here is described how to call an Adapter REST Service from the TIVITY platform in a simple way. The prerequisite for this is a running REST service with the mandatory service method calls (see Adapter documentation). The service must be callable from "outside", that means, the platform must be able to call the adapter URL.

Create class for adapter

First of all, after the source has been configured, a class must be created in the ClassDesginer. To do this, before adding a new class, a source must be selected. At the top right of the ClassDesginer are the available data sources. There you can select the Adapter Service you have previously set up. If the source is not available in the list, you can optionally select it using the "Add Data Source" button.

After the adapter class has been set up, it is sufficient to name the key and mapping, a class action can now be created. In the settings of this Action on the Common tab the Execution / ValidOn value "Class" must be selected.

Of course, the internal key and the mapping key must also be entered. As Result Data Type you first select String to be able to test it better later.

Connection between class action and service call

A class that has a service adapter as DataSource automatically connects to the source. This means that when certain class actions are executed, these are those that were already created in advance for a newly created Main-Base-Class, a call to the service is started. These specific actions include Delete, New, Read and List. For this, there is an Adapter Service corresponding calls (Capabilities). See the documentation on the RESTful Adapter Service and Service Adapter Interfaces.

All new actions created by the user go to the Execute method of the service. The request object of an execute call contains the name of this action and the name of the class under which this action is called. You can also specify other parameters (see next chapter about workflows).

For our example (above in the chapter), this means that when triggering the newly created action "QueryService", the Execute call is started with the Name "QueryService" as ActionName in the request. You can then react to the call from there.

A workflow for a simple call of an execute action

A workflow can be created for the direct call of the Adapter Service, which can then be called from the app. First create a workflow as usual. You can select a class from the app as the class in settings.

The script consists of only two local variables for simplicity. The Request variable, which contains a message that is sent to the adapter service is sent. And ResultValue, where the response from the service is stored.

To initiate the service call now, the script action "ExecuteClassAction" must be executed. The necessary parameters are the OfficeId, ApplicationId and ClassId, Since we assume that the workflow is started in the same app as the Adaper Service class, we can take the IDs from the context. However, the ClassId has to fetch via "Get System Id".

Further the ActionId is still needed. There the action is specified, which we have previously created in ClassDesigner. This ID is also fetched with "Get System Id". Optional is nor the parameter dictionary. However, since we want to send a message to the service, we add the request to the dictionary.

Any number of values can be transferred to the Adapted Service in the form of an entry (key value pair). In this example it is the key "MyRequest" which contains the message from the variable Request.

To the test you can now add a Message script action and output the ReturnValue.