Here are some common errors that occur when invoking Workflows via REST API.

API response is "There is no service at this location."

This error is presented for one of two reasons:

  1. No Workflow is bound to a URI template that matches the one requested
  2. Two or more Workflows were bound to a URI template that matches but because the match is ambiguous, neither one is served
  3. As an extension on point 2, bear in mind that if Release Management is in use, it may not be the latest revisions of two Workflow that have the same URI template. The Workflows list shows the URI template of the latest revision whereas there may well be older revisions of a Workflow in the Production Site Environment

To identify which Workflows have the same URI template, look for the API binding information that presents in the Workflows list. For example, if your path is /thing/foo, you have two Workflows that are bound to /thing/foo.

The wrong Workflow fires up when a call is made


Here are the reasons this can occur:

1. Workflow routes can be ambiguous

It is possible to define a route that could include another route. For example, one workflow might be bound to GET /customers/{id} while another to GET /{object}/{id}.

Flowgear doesn't sort the available matches routes by how closely they match so the Workflow that is selected is not guaranteed to be stable.

To prevent this problem, use routes that you can statically determine to be mutually exclusive. For example, either have a single Workflow bound to GET /{object}/{id} and have that Workflows hand off to sub-workflows depending on whether object is 'customer' or 'order', etc.

Alternatively, create separate Workflows that do not specify route segments that are dynamic in some Workflows and static in others. For example, in the route GET /{object}/{id}, segments 1 and 2 are both dynamic. Rather create Workflows with a statically defined first segment to prevent ambiguity. For example, GET /{customers/{id} and GET /orders/{id}

2. The Workflow is firing up under a different Site Environment

Consider whether the Workflow is being invoked in the expected Site Environment (e.g. 'Test' or 'Production'). If Release Management is enabled, it may be that the latest revision of your Workflow shows the correct route but an older outdated route is published into the 'Production' environment.

By default, API calls will fire up the Workflow against the 'Production' Environment but the _profile querystring element can be used to override the Site Environment.

You can verify which Site Environment the Workflow was invoked via by Looking at the InitialisationXml Property in the Start Activity Log.

Did this answer your question?