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.
1) Correctly position the label on new data objects
2) When a Data Object is removed, remove all its references as well.
3) Avoid duplicate names showing up in the Data Objects list.
4) Allow non-words in data object names.
Fix the SpiffExtensions so they work consistently with both nested Extension Properties, and as single extensions depending on the namespace.
Add a Spiff Extension Text Area.
Everything that is within the body of tag can be referenced with ".value" -- there was a lot of pointless inconsistency in the moddle json file.
Json files are now a selection list, not a text field -- see app.json for usage.
New SpiffExtensionSelect can be used to add select boxes anywhere you want.
use commandStack to update Moddle Properties.
Providing a working example of using a code editor with this library, so it's clear how the integration would work.
Rename titles of various components -- don't call sections "SpiffWorkflow", but maybe we find a way to more gently call out these extensions later on.
* When all data input and outputs are removed, the ioSpecification should be removed as well
* If an ioSpecification is present, then there shoud be a at least one dataInputset and at least one dataoutputset.
Fixes this so that only if you delete all references, wii the data object be removed.
Also assures that a new data object is not created when adding to a participant in a collaboration (an edge case bug(.
