Response status handling

Each OData connector call response contains standard variables.

• StatusCode (HTTP response code),

• ErrorMessage

• HasFailed (True/False).

Three standard attributes

Error handling

Developers can control how Flow reacts when the request fail, the response variable HasFailed = true:

• Ignore, execution of the flow continues

• Check HasFailed in decision step in flow and act accordingly

• Let the Flow server break the machine step automatically

OData connector has "Break workflow on error" -feature to control how individual steps reacts to errors. The feature can be controlled in OData connector configuration and individually within each machine step.

Setup on connector level

The "Break workflow on error" feature in OData connector configuration in Connector service.

The connector service configuration reflects the value in connector setup in Flow Studio and is the default setup for all flows using the configuration. Notice you can also change this in Studio which will reflect the value in Connector Services.

Default value of Break Workflow on error in Connector setup

Overriding default setup in machine steps

It possible to override the "Break workflow on error" connector default value in the OData machine steps.

Overriding setup in CUD and action/function operations

Overriding setup in Read operation

If the setting is set to "true", the machine step will stop the execution of the workflow and typically display a dialog with an error message. Examples of error message on workflow break on error:

Break workflow on error = true

If set to false - do not break - it is up to the workflow designer to check the HasFailed and/or StatusCode member of the result (and/or ErrorMessage) and decide whether to break the workflow, try again, or just ignore it.

Status Codes

Possible HTTP response Status codes returned by each call can be found in the API documentation found via the IFS API Explorer.

Common successful execution status codes starts with 2

• 200 (read operations, functions)

• 201, 204 (CUD operations, actions)

Unsuccessful status code start with 4 or 5

• 40x error codes refers to client error where transaction in IFS has failed (wrong data, business rule violations)

• 50x error codes refers to server error (service unavailable = IFS down, authentication error, but also business errors, like wrong parameters in Create operations)

IFS return either 40x or 50x errors in case of business logic error upon CUD operations.

IFS error response

Upon error IFS returns error in following JSON structure (may be exceptions):

Example:

{
  "error": {
    "code": "DATABASE_ERROR",
    "message": "Database error occurred. Contact administrator.",
    "details": [
      {
        "code": 20124,
        "message": "ORA-20124: Error.NULLVALUE: Field [NAME] is mandatory for Person Info and requires a value."
      }
    ]
  }
}

This JSON is returned by the Machine Step as a string in the ErrorMessage attribute.

OData Machine Step output

You can use flow script to extract error if needs to be beautified to end user or for other logging purposes.

Error handling fragment

It's good practice to create a Error handling fragment that you can insert after each call to handle error, the variable HasFailed = True. Fragment would process the generic response and extract errorMessage. This is then the output from the fragment.

// Add here example of how to parce ErrorMessage in flow script