Bizagi features an OData service which handles aspects of the Experience design.
Through the Searches URI, you can handle data related to searches provided to Stakeholders, as described at Search execution results and data.
This section describes how to obtain actions of records returned by searches and eventually execute them.
Actions considered by this service are those which trigger new processes.
Actions which execute rules or launch forms are not supported.
Start with this URL:
•[search_ID]: The ID of a specific search, as returned in Searches execution results and data.
•[result_ID]: The ID of a specific recording, as returned when executing a search via Searches execution results and data.
•[your_bizagi_project_url]: The URL where end users access your Bizagi Work Portal.
For an on-premise Bizagi project, the URL would be:
For Automation Service projects, the URL would be:
This image illustrates how you can send an HTTP GET for a resource:
Returned results include (inside the value element):
•Name: The unique name of the action for that record.
•DisplayName: The default display name of the action for that record.
•@odata.id: The unique URL to access that action.
•Id: A string-based GUID representing the URI of that search.
•Parameters: The list of data (attributes) that such actions needs to run.
Parameters are included for each attribute:
oId: A string-based GUID.
oName: The display name.
oXpath: The full Xpath to that attribute (includes its name).
oType: The data type. For a list of possible values regarding data types in Bizagi, refer to Types of data.
Every set of results returned by the OData services includes a set of standard properties which are preceded by the @ sign. These properties are described in Properties and querying options.
Through the @odata.id property, you can obtain a specific record's detail only, instead of a full list.
For example, use:
For a given action, you can send parameters and execute it to start a case.
To trigger an action which starts a new case, invoke this URL by means of an HTTP POST:
Consider including the following JSON structure in the body to send parameters:
•[xpath_name]: The exact Xpath expected by parameters of that process' triggering action.
•[xpath_datatype]: The data type for the Xpath as expected by each parameter..
•[value_for_xpath]: The value you want to set for the Xpath parameter.
If you have more than one parameter, use:
If no parameters are expected, use:
The next image illustrates data in the body you can send in an HTTP POST and the response you obtain indicating the case number of the created case (in the returned value):
The next image shows a previous invocation regarding parameters that the action expects (as you would need to send the exact data type and matching xpath information):
Refer to the following links for specific use cases:
•To filter the search with parameters, consider the notes for the different data types at Values and formats for data types.
•To dynamically obtain business values that you may need as input parameters to start a new process or complete an activity, refer to Related entities services.
•To dynamically obtain the columns you need to fill out to send when creating records in a collection, refer to Columns in collections.
•To learn how to comply to the format expected when sending dates, files and images or Boolean fields, refer to Sending input parameters.