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:
No Workflow is bound to a URI template that matches the one requested
Two or more Workflows were bound to a URI template that matches but because the match is ambiguous, neither one is served
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.
3. The parameters in the URL of an existing API-bound workflow have been changed
To optimise throughput, Flowgear doesn't re-cache a route unless an attempt is made to open one that doesn't exist in the cache. This ensures the best possible performance when a route matches but can mean that changes to the URL of an existing route aren't seen until the routes are next re-cached.
You can force an immediate re-cache of routes for your Site by requesting a URL that doesn't exist. The API server your request is serviced through will see that there is no existing route for that URL and will re-cache all routes for the Site.