Hi, I want to get process instance history in Camunda 8.7 using camunda-spring-boot-starter or rest APIs, please advise how to accomplish this.
Hi! Great question about getting process instance history in Camunda 8.7.
Classification: This is a General Question about how to retrieve historical data.
In Camunda 8, the architecture for accessing historical data is different from Camunda 7. Here’s what you need to know:
Key Architecture Change
Camunda 8 separates runtime and history data. Historical data is not accessed directly from the engine but is exported to Elasticsearch. You need to use dedicated APIs like Operate API or the Query API to access historical process instance data.
Available Options for Camunda 8.7:
1. Operate API (Recommended)
The Operate API is stable and the recommended approach for retrieving process instance history. You can use the /v1/process-instances/search endpoint.
Example request:
POST /{clusterId}/v1/process-instances/search
Content-Type: application/json
{
"filter": {
"state": "COMPLETED",
"startDate": {
"from": "2024-01-01T00:00:00Z",
"to": "2024-01-31T23:59:59Z"
}
}
}
2. Query API (Alpha in 8.7)
Camunda 8.7 introduced a Query API for process instances, but it’s still in alpha and must be explicitly enabled. This API offers more advanced filtering capabilities and will become GA in Camunda 8.8.
3. Spring Boot Starter Limitation
The camunda-spring-boot-starter in Camunda 8 is primarily for integrating with the Zeebe engine for runtime operations, not for querying historical data. For history, you should use the REST APIs mentioned above.
Documentation References:
Next Steps:
- Use the Operate API for stable historical data access
- If you need advanced filtering, consider enabling the alpha Query API
- Let me know your specific use case if you need more detailed examples!
Would you like me to provide more specific examples for your particular filtering or data retrieval needs?
The process-instances/search REST API returns only the process instance main details, and I want to retrieve all the actions and paths taken, like Operate.
Perfect! You want the detailed execution history like what you see in Operate’s interface. Here’s how to get all the actions and paths taken by a process instance:
Complete Process Instance History via Operate API
To get the full audit trail and execution path (like Operate shows), you need to use multiple endpoints to gather all the detailed information:
1. Flow Node Instances (Main Execution Path/Audit Trail)
This is the key endpoint for getting all activities, tasks, and execution steps:
POST /v1/flownode-instances/search
{
"filter": {
"processInstanceKey": "YOUR_PROCESS_INSTANCE_KEY"
}
}
This returns all flow node instances for your process instance, including:
- User tasks, service tasks, gateways, events
- Start/end times for each activity
- State of each flow node (ACTIVE, COMPLETED, TERMINATED, etc.)
- Flow node type and name
- This forms the complete execution path and audit trail
2. Incidents (Errors and Exceptions)
Get any incidents that occurred during execution:
POST /v1/incidents/search
{
"filter": {
"processInstanceKey": "YOUR_PROCESS_INSTANCE_KEY"
}
}
3. Process Instance Metadata
Get high-level process instance information:
GET /v1/process-instances/{processInstanceKey}
4. Flow Node Statistics (Optional)
Get aggregated statistics for each flow node:
GET /v1/process-instances/{processInstanceKey}/statistics
Complete Example Workflow:
- Start with the process instance key you want to analyze
- Call
/v1/flownode-instances/search- this gives you the detailed execution path - Call
/v1/incidents/search- this gives you any errors/exceptions - Optionally call the other endpoints for additional metadata
The flow node instances endpoint is the most important one as it provides the detailed audit trail showing exactly which activities were executed, when they started/completed, and their sequence - essentially replicating what you see in the Operate UI.
Documentation References:
Does this approach give you the level of detail you’re looking for? Let me know if you need help with authentication or specific response format examples!
Flow Node Instances Search does the job, actually. Is there any API to do the same in Spring Boot SDK?
Great question! Unfortunately, the camunda-spring-boot-starter does not provide direct access to the Operate API or historical data like flow node instances. The Spring Boot SDK is primarily for runtime operations with the Zeebe engine.
However, you have two good options for accessing flow node instances from a Spring Boot application:
Option 1: Community Java Client (Recommended)
There’s a community-maintained Java client specifically for the Operate API:
This client provides a Java-friendly way to interact with the Operate API, including searching for flow node instances. You can add it to your Spring Boot project and use it to retrieve the detailed execution history.
Option 2: Spring Boot REST Clients
Use standard Spring Boot HTTP clients like RestTemplate or WebClient to call the Operate API directly:
@Service
public class OperateService {
@Autowired
private RestTemplate restTemplate;
public List<Map<String, Object>> getFlowNodeInstances(String processInstanceKey) {
String url = "http://localhost:8080/v1/flownode-instances/search";
Map<String, Object> filter = Map.of("processInstanceKey", processInstanceKey);
Map<String, Object> request = Map.of("filter", filter);
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON);
// Add authentication headers as needed
HttpEntity<Map<String, Object>> entity = new HttpEntity<>(request, headers);
ResponseEntity<List> response = restTemplate.exchange(
url, HttpMethod.POST, entity, List.class);
return response.getBody();
}
}
Key Points:
- No direct SDK support: The Spring Boot SDK doesn’t include Operate API functionality
- Authentication required: You’ll need to handle authentication (bearer token, cookies, etc.) based on your setup
- Community client is preferred: It provides better type safety and easier integration
Documentation References:
I’d recommend starting with the community Java client as it’s specifically designed for this use case and will give you a more robust integration than raw REST calls.
Would you like help with setting up either of these approaches?