Duplicate Key violation

45 views
Skip to first unread message

Steve O

unread,
Nov 2, 2021, 11:51:16 PM11/2/21
to nflow-users
I am able to execute a single workflow after starting up the system using the in memory database.  But if I attempt to execute the same workflow with different parameters a second time, I get the following:

20:43:18.506 WARN [https-jsse-nio-8888-exec-3] io.nflow.engine.internal.dao.WorkflowInstanceDao [WorkflowInstanceDao.java : 247] - Failed to insert workflow instance

org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; Unique index or primary key violation: "PUBLIC.NFLOW_WORKFLOW_UNIQ ON PUBLIC.NFLOW_WORKFLOW(TYPE, EXTERNAL_ID, EXECUTOR_GROUP) VALUES 1"; SQL statement:

insert into nflow_workflow(type, priority, parent_workflow_id, parent_action_id, business_key, external_id, executor_group, status, state, state_text, next_activation, workflow_signal) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-200]; nested exception is org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: Unique index or primary key violation: "PUBLIC.NFLOW_WORKFLOW_UNIQ ON PUBLIC.NFLOW_WORKFLOW(TYPE, EXTERNAL_ID, EXECUTOR_GROUP) VALUES 1"; SQL statement:

insert into nflow_workflow(type, priority, parent_workflow_id, parent_action_id, business_key, external_id, executor_group, status, state, state_text, next_activation, workflow_signal) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-200]

It seems like there is a bug in the workflow logic that prevents multiple instances of the workflow from executing.

nflow-users

unread,
Nov 3, 2021, 3:02:25 AM11/3/21
to nflow-users
Hi,

ExternalId of workflow instance must be unique within same workflow definition type and executor group. If you don't provide externalId when creating the instance, nFlow will automatically generate a unique externalId for the instance. If you want to connect multiple instances to the same external entity, you should use businessKey for that purpose, as it allows using the same value in multiple workflow instances.

br. Edvard

Steve O

unread,
Nov 3, 2021, 11:25:50 AM11/3/21
to nflow-users
Edvard thanks for the response.  Perhaps you could help me understand the model here.  I am not sure what an executor group is, and I don't understand exactly what an instance is in this context. 

 I thought I did but clearly I do not.  If I want to accept a request and run that request through a series of steps (states or whatever) producing some output along the way, I thought that was what we refer to as a workflow.  I thought that every time we run a start message through some workflow, that is a workflow instance.  

Thus I have a method on my REST api which looks pretty much like this:

@RequestMapping(path = "/submitRequest", method = RequestMethod.POST, 

consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)

public RequestStatus submitRequest(@RequestBody AccessRequest postBody) {

try {

RequestStatus requestStatus = accessRequestTableRepo.recordNewRequest(postBody);

workflowInstances.insertWorkflowInstance(

workflowInstanceFactory.newWorkflowInstanceBuilder().setType(DemoAccessWorkflow.TYPE)

.setExternalId("demoAccess")

.putStateVariable(DemoAccessWorkflow.REQUEST_ID, requestStatus.requestId).build());

return requestStatus;

} catch (ServiceException e) {

throw e;

} catch (Exception e) {

throw new ServiceException("Failure in submitRequest", e);

}

}


The first time I call this method I get expected results, the second and any subsequent time I call it I get the errors I mentioned previously.  So I guess I am not supposed to be calling this InsertWorkflowInstance method multiple times. But then for the life of me I can't figure out how to do something as basic as implement this rest method while sharing the same workflow, not to mention wanting to do a real clustered deployment with multiple workflows running in parallel.


--
You received this message because you are subscribed to the Google Groups "nflow-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nflow-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nflow-users/45b23e09-7413-49b3-bdbe-37ab1c6d55efn%40googlegroups.com.

nflow-users

unread,
Nov 4, 2021, 3:52:05 PM11/4/21
to nflow-users
Hi,

You're welcome :)

I don't think you need to worry about executor groups in your case - it's a feature that allows multiple nFlow engine (executor) "clusters" to use the same database. And if you think workflow definition is like a class in Java, then workflow instance is like an object.

So, if I have understood you use case correctly, you should create one workflow instance (of type DemoAccessWorkflow) per access request, so the external ID should be the unique ID of the access request (postBody.requestId?). If you try to create a workflow instance for the same access request again (with an external ID that already exists), nFlow works as designed: logs a warning about it but does not create a duplicate workflow instance.

And if you really want to create another workflow instance to handle another access request, you need to use a different external ID (postBody.requestId) for it.

So, you can have multiple workflow instances of the same (workflow definition) type, but the external IDs of those instances must be unique.

HTH, Edvard
Reply all
Reply to author
Forward
0 new messages