This page called Grumman analyses your messages usage and fixes issues in multiple situations :
- Reconcilation stuck
- Incomplete message
- Error on operation behind a message
- Duplicate send message
This page will help you as a developer debugging and fixing issues quite faster and with less manual actions.
You can find this contribution made by Pierre-yves Monnet in the projects section.
Anyway, there are bad practices to avoid. Don't forget that messages are saved forever, and one message matches one case. The event is frozen until a message is catched up.
Therefore practices to avoid are the following :
-
Manually unblock process instance
-
Message consumption :
<ul> <li> <p>Do not send a message where no process instance will be matched</p> </li> <li> <p>Do not send multiple messages</p> </li> <li> <p>When a receiver is a boundary event, do not send the message if the process instance is not in the task, or will never come again in the task</p> </li> <li> <p>When the receiver is a Sub Process Event, this is the same situation. If the case is already archived, the message will be saved forever</p> </li> </ul> </li> <li> <p>Verify the content of the message</p> <ul> <li> <p>A message is supposed to be an internal emission between two processes. Studio checks the content of the message. Then, for example, if the design affects a variable from the value “message.motorOfCar”, and this content does not exist in the definition message, the studio detects it and produces an error at the design level.<br /> So, when the message is sent by the API and is not correct, the Bonita Engine executes the message, and face an error. In that situation, message and process instances are stuck.</p> </li> <li> <p>If the sender is not “safe”, the best approach is to use a Human task. A human task has a Contract, and then the Bonita Engine check if all data are correctly provided. If not, an error is produced, and task stays in the same situation</p> </li> </ul> </li>
See details in the project description.