Accessing Services Deployed in FlexRule Server

◷ Reading Time: 13 minutes

To access deployed services in FlexRule server requires an API development environment to test the API. In this example we use Postman to send the request.

Prior to testing in Postman there is a requirement to publish your application.
See how you can publish your project in different ways.

Execution can be done in either sync or async manners.

In this tutorial, we will explain how to,

  1. Get Bearer Token
  2. Test the Service URL
  3. Test the Service URL in async manner
  4. Test a Workflow

Get the Bearer Token

Getting the bearer token is the first step of accessing deployed services in FlexRule server

In FlexRule Server Version 9.1, use Master Management address

You will get the Access Token

Postman screen showing settings to request bearer token
Workbench Test run view showing how bearer token can also be taken from there.
The token can also be taken from the Test Run result of the FlexRule Server workbench instead of using the above URL.

Test the Service URL

First, get the Bearer Token following the above steps under Get the Bearer Token.
Then you can test the Service URL.

Request

Request Structure

Request {
    EnableFullLog (bool)

[Server version 9.2 ==> fullLog (bool) and also 
"fullLog": "server" --> so the log is written to the Server and receive only a URL to the log in the response object]

,
    CorrelationId (string), 
    Actor (string),
    
    // Input parameters of the model (or the service)
    Inputs (array):[
         {
             Name (string),
             Value (object)
         }, ...
    ],

    // Service selection strategy options
    UseEarliestVersion (bool),
    UseLatestVersion (bool),
    ServiceKey (string),
    ServiceVersion (string),

    // Workflow and long running behaviour
    Workflow: {
      WorkflowInstanceId (string),
      QueryTasks (bool),
      ResumeInfo: {
           Title (string),
           Category (string),
           Outcome (string)
       } 
}

The request should have the following properties:

  • Method
  • Service URL
  • Authorization (Type, Token)
  • Body (Input text/ object, Content-Type)
  • Header (Authorization, Content-Type)

Now let’s discuss these in detail.

Method: POST

Service URL: <Working Service Url of the package>

Note: If you have multiple different services under the same package, it requires using the service version
e.g. http://localhost:9000/api/services/execute/dc/1/Calculator1?serviceVersion=1

Authorization:

  • Type: ‘Bearer Token’
  • Token: <Access Token>
Postman view showing the bearer token added to the Auth tab

Body: <Your input JSON object>

Postman Body tab showing request JSON input

Inputs are a set of name-value pairs. Name is the name of the parameter, and Value is the value of the parameter. Inputs must be provided in a name/value format as the above Request specification indicates.

{ 
  "inputs": [
            {
              "name": "person",
              "value": {
                "Age":20
              }
            }
        ]
}

Headers:

  • Authorization: <Type and Token> (This will be autofilled in Postman, after adding Authorization Type and Token)
  • Content-Type: application/json (This will be autofilled in Postman, after adding Body by selecting JSON (application/json))
Postman Headers view showing the required Headers information input

Response

Response Structure

Response {
    InvocationId (string),
    CorrelationId (string), 
    errorCode (string),
    messageId (string),
    isError (bool),

    
    result:
    {
         Output (array): [{
             Name (string),
             Value (object)
         }...],
         Notification (array),
         ConclusionLog(string), 
         Elapsed (timespan), 
    }

    ExtraOutput (array):[],
    WorkflowInstanceId (string),
    Exception (string),
    Agent (guid),
}

Once you send the Request, the Response can be seen as follows:

Postman Body view showing response object JSON

This sample is attached at the end of the page (AgeDecision.zip).

Test the Service URL in Async Manner

First, get the Bearer Token following the above steps under Get the Bearer Token.
Then you can test the Service URL in async manner.

1. Call the service with ?async=true:

Request

The request should have the following properties:

  • Method
  • Service URL
  • Authorization (Type, Token)
  • Body (Input text/ object, Content-Type)
  • Header (Authorization, Content-Type)

Now let’s discuss these in detail.

Method: POST

Service URL: <Working Service Url of the package> ?async=true

  http://localhost:9000/api/services/execute/timeoutwithresult/1/GenericFlow?async=true 

Authorization:

  • Type: ‘Bearer Token’
  • Token: <Access Token>
Postman view showing the bearer token added to the Auth tab

Body: <Your input JSON object>

Postman body tab showing empty array input for async request

Inputs are a set of name-value pairs. Name is the name of the parameter, and Value is the value of the parameter. Inputs must be provided in a name/value format as the above Request specification indicates.

If there is no input, you can pass an empty input array like the above image.

{ 
  "inputs": [
            {
              "name": "person",
              "value": {
                "Age":20
              }
            }
        ]
}

Headers:

  • Content-Type: application/json (This will be autofilled in Postman, after adding Body by selecting JSON (application/json))

2. When you send this request, you will receive the location indicating where the result can be retrieved.
Note the result code is 202, rather than 200 for a normal call.

Postman Body tab showing the URL for the response from an async request

Location Request

3. Click on the received location link.
It will open a new tab with a GET request URL

Postman view showing the GET location for response

Now use the same information used in the above POST Request

Authorization:

  • Type: ‘Bearer Token’
  • Token: <The same access token>
Postman view showing the bearer token added to the Authorixation tab when getting the response

Body: <The same input JSON object>

Postman view showing the input for response in body tab when getting the response

4. Click Send and you will receive 500 or 503 code until your results are getting ready.
You can try sending the request multiple times. If the results are not ready you will keep getting the same code.

Postman view showing 500 error  for response when the request is still pending

5. Click send again after a few minutes. If your response is ready you will get the result with code 200.

Postman view showing successful response

This sample is attached at the end of the page (Async Example.zip).

Test a Workflow

First, get the Bearer Token following the above steps under Get the Bearer Token.
Then you can test the workflow.

1. Start the workflow

Initial Request

The request should have the following properties:

  • Method
  • Service URL
  • Authorization (Type, Token)
  • Body (Input text/ object, Content-Type)

Now let’s discuss these in detail.

Method: POST

Service URL: <Working Service Url of the workflow package>

Authorization:

  • Type: ‘Bearer Token’
  • Token: <Access Token>
Postman view showing the bearer token added to the Auth tab

Body: <Your input JSON object>

Postman Body tab showing request JSON input as empty array for a Workflow request

Inputs are a set of name-value pairs. Name is the name of the parameter, and Value is the value of the parameter. Inputs must be provided in a name/value format as the above Request specification indicates.

If there is no input variable, send an empty array of input as above image.

{ 
  "inputs": [
            {
              "name": "person",
              "value": {
                "Age":20
              }
            }
        ]
}

Initial Response

Once you send the Request, the Response can be seen as follows:

You will see details such as,

  • state (waiting, completed, etc.)
  • workflowInstanceId
  • outcomes (Only if your project has outcomes)
Postman Body tab showing the initial response for a workflow request

Now your workflow is waiting for human interaction.

Resume Workflow

2. Now you can resume the workflow

Postman Body tab showing the resume workflow

The following request shows a sample input. From the initial response, copy the following items to create the resume request.

  • workflowInstanceId
  • Title
  • Outcome

So you can use the same request updating the highlighted sections.

 {
    "EnableFullLog": true,
    "CorrelationId": null,
    "Actor": null,
    "inputs": [],
    "UseEarliestVersion": true,
    "UseLatestVersion": true,
    "ServiceKey": "WorkflowWorkflowtest",
    "ServiceVersion": "1",
    "Workflow": {
        "WorkflowInstanceId": "8ac0db20-4fe2-b7d2-8211-08d85941c63e",
        "QueryTasks": false,
        "ResumeInfo": {
            "Title": "Write",
            "Category": null,
            "Outcome": "Submit"
        }
    }
} 

When you test using Postman, “QueryTasks” should be false.

3. Then you will receive the second response with the next set of outcomes.

Postman Body tab showing the resume workflow for second response

4. Repeat the request only updating the Title and Outcome from the previous response.

Postman Body tab showing the resume workflow for second response

5. If there are no more steps, you will get the response with the state “completed”

Postman Body tab showing the completed workflow response

This sample is attached at the end of the page (Publish Profile-sample.zip).

Video Tutorial

Download the Sample

Use the attachments at the end of the page to download the sample package to upload and test.

  1. AgeDecision.zip: A sample input has been added as a Logic Run Template
  2. Async Example.zip: This sample does not have any input
Updated on February 20, 2024

Article Attachments

Was this article helpful?

Related Articles