Bizagi features an OData service which handles aspects of the Experience design.
Through the Searches URI, you may handle data related to searches provided to Stakeholders, as described at Searches execution results and data.
This section describes how to obtain actions of records (and eventually execute them), as returned by searches.
Actions considered by this service are solely those which trigger new processes.
Actions which execute rules or launch forms are not supported.
Start off from the following 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]: Corresponds to the URL where end users access the Bizagi Work portal.
For instance for an on-premise Bizagi project, such URL would be:
While for Bizagi PaaS projects, such URL would be:
The following image illustrates how you can send an HTTP GET for this resource:
Returned results consider (inside of 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 specific action.
•Id: A string-based GUID representing the URI of that specific search.
•Parameters: The list of data (attributes) that such actions needs in order to run.
Such parameters include for each attribute:
oId: A string-based GUID of the attribute.
oName: The display name of the attribute.
oXpath: The full Xpath to that attribute (includes its name).
oType: The type of data of the attribute. For a list of possible values regarding data types in Bizagi, refer to Types of data.
In addition to the above, for every set of results returned by the OData services, the successful response includes a set of standard properties which are preceded by the @ sign. Such properties are described at Properties and querying options.
Notice how through the @odata.id property, you can obtain that specific record's detail only, instead of a full list.
For example using:
For a given action, you may send out parameters and execute it to start a case.
In order to trigger an action which starts a new case, the URL described below is invoked by means of an HTTP POST:
Consider including the following JSON structure to send parameters in the body:
•[xpath_name]: The exact Xpath as expected by parameters of that process' triggering action.
•[xpath_datatype]: The data type for that Xpath as expected by each parameter..
•[value_for_xpath]: The value you want to set to such Xpath parameter.
Notice if you have more than 1 parameter, you would use:
Similarly, if no parameters are expected, you would use:
The following 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 (at the returned value):
Notice this other 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, as described at Values and formats for data types.
•To dynamically obtain business values that you may need as an input parameter 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.