1) Type Safe checking on correlation properties (no more str())
2) A running workflows Correlations are once again at the key level.
# Backend
1) Both send and receive messages can have correlation_keys - and we compare these to each other to quickly assure a match (if they both exist - otherwise we fall back to comparing the properties on the receive to the sending messages payload)
2) Cleaned up the migrations to just one file
Adding a correlation cache - so we have a reference of all the messages and properties (though still lacking a description of keys)
Adding yet another migration, maybe should squash em.
SpiffWorkflow -
- start_messages function should return message names, not ids.
- don't catch external thrown messages within the same workflow process
- add an expected value to the Correlation Property Model so we can use this well defined class as an external communication tool (rather than building an arbitrary dictionary)
- Added a "get_awaiting_correlations" to an event, so we can get a list of the correlation properties related to the workflows currently defined correlation values.
- workflows.waiting_events() function now returns the above awaiting correlations as the value on returned message events
Backend
- Dropping MessageModel and MessageCorrelationProperties - at least for now. We don't need them to send / receive messages though we may eventually want to track the messages and correlations defined across the system - these things (which are ever changing) should not be directly connected to the Messages which may be in flux - and the cross relationships between the tables could cause unexpected and unceissary errors. Commented out the caching logic so we can turn this back on later.
- Slight improvement to API Errors
- MessageInstances are no longer in a many-to-many relationship with Correlations - Each message instance has a unique set of message correlations specific to the instance.
- Message Instances have users, and can be linked through a "counterpart_id" so you can see what send is connected to what recieve.
- Message Correlations are connected to recieving message instances. It is not to a process instance, and not to a message model. They now include the expected value and retrieval expression required to validate an incoming message.
- A process instance is not connected to message correlations.
- Message Instances are not always tied to a process instance (for example, a Send Message from an API)
- API calls to create a message use the same logic as all other message catching code.
- Make use of the new waiting_events() method to check for any new recieve messages in the workflow (much easier than
churning through all of the tasks)
- One giant mother of a migration.
* SpiffWorkflow did not serialize correlations - so they were lost between save and retrieve.
* When comparing Correlation Property values - we are storing these values as strings in the database and can't convert them back to integers later, so I'm changing everying everywhere to compare after conversion to a string. Don't feel great about this one.
* By using an SQL Alchemy join table, there is a lot of db queries we don't need to write.
* A few handy fucntions on db models to make it easier to work with correlations.
* Updated tests because I changed some of the BPMN models we were testing against.
* Database migration to use the new constraint names with the alternate form of the join table between correlation mesages to instance messages.
* Clear out complex get_message_instance_receive how that many-to-many works.
* Create decent error messages when correlations fail
* Move correlation checks into the MessageInstance class
* The APIError could bomb out ugly if it hit a workflow exception with not Task Spec.
Adding a bit of detail to the spiffworkflow exceptions when a duplicate process model is found.
Disable the submit button on tasks after you click submit (avoid the double click and give users a better experience)
