Squashed 'SpiffWorkflow/' changes from 7b39b2235..b3235fad5

b3235fad5 Merging main
09623ca61 # SpiffWorkflow: 1) Type Safe checking on correlation properties (no more str()) 2) A running workflows Correlations are once again at the key level.
d6806f69d maintain a way to access the correlations in relation to the correlation keys
065a86cde BPMN Parser was returning all retrieval expressions, rather than the ones specific to a correlation property, as was intended. 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.
9e8832c93 Merge remote-tracking branch 'origin/main' into feature/message_fixes
8efa922ae run_pyl
72a7e535a BPMN.io -- Just show the message names not the ids - to assure we are only exposing the names. 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.
cb2ff8a93 * SpiffWorkflow event_definitions wanted to return a message event's correlation properties mested within correlation keys.  But messages are directly related to properties, not to keys - and it forced a number of conversions that made for tricky code.  So Messages now contain a dictionary of correlation properties only. * SpiffWorkflow did not serialize correlations - so they were lost between save and retrieve.
d4852a1a5 * Re-work message tests so I could wrap my simple head around what was happening - just needed an example that made sense to me. * 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.

git-subtree-dir: SpiffWorkflow
git-subtree-split: b3235fad598ee3c4680a23f26adb09cdc8f2807b

tests/SpiffWorkflow/bpmn/CollaborationTest.py

@@ -50,7 +50,18 @@ class CollaborationTest(BpmnWorkflowTestCase):
         self.assertEqual(len(messages), 1)
         self.assertEqual(len(workflow.bpmn_messages), 0)
         receive = workflow.get_tasks_from_spec_name('EventReceiveLetter')[0]
-        workflow.catch_bpmn_message('Love Letter Response', messages[0].payload, messages[0].correlations)
+
+        # Waiting Events should contain details about what we are no waiting on.
+        events = workflow.waiting_events()
+        self.assertEqual(1, len(events))
+        self.assertEqual("Message", events[0]['event_type'])
+        self.assertEqual("Love Letter Response", events[0]['name'])
+        self.assertEqual(['lover'], events[0]['value'][0].correlation_keys)
+        self.assertEqual('from_name', events[0]['value'][0].retrieval_expression)
+        self.assertEqual('lover_name', events[0]['value'][0].name)
+
+        workflow.catch_bpmn_message('Love Letter Response', messages[0].payload,
+                                    messages[0].correlations)
         workflow.do_engine_steps()
         # The external message created above should be caught
         self.assertEqual(receive.state, TaskState.COMPLETED)

tests/SpiffWorkflow/camunda/StartMessageEventTest.py

@@ -17,7 +17,7 @@ class StartMessageTest(BaseTestCase):
     def testParserCanReturnStartMessages(self):
         parser = self.get_parser('message_test.bpmn')
         self.assertEqual(
-            parser.process_parsers['ThrowCatch'].start_messages(), ['Message_1rkbi27'])
+            parser.process_parsers['ThrowCatch'].start_messages(), ['ApprovalRequest'])
 
         parser = self.get_parser('random_fact.bpmn')
         self.assertEqual(

tests/SpiffWorkflow/spiff/CorrelationTest.py

@@ -49,7 +49,11 @@ class DualConversationTest(BaseTestCase):
         self.assertEqual(len(messages), 2)
         message_one = [ msg for msg in messages if msg.name== 'Message Send One' ][0]
         message_two = [ msg for msg in messages if msg.name== 'Message Send Two' ][0]
-        self.assertIn('message_correlation_key_one', message_one.correlations)
-        self.assertNotIn('message_correlation_key_one', message_two.correlations)
-        self.assertIn('message_correlation_key_two', message_two.correlations)
-        self.assertNotIn('message_correlation_key_two', message_one.correlations)
+
+        # fixme:  This seemed to test that we get a nested structure of correlation keys and correlation properties
+        # Perhaps there should be a way to get the keys and thier associated properties - but things should not default to a nested structure.
+
+        # self.assertIn('message_correlation_key_one', message_one.correlations)
+        # self.assertNotIn('message_correlation_key_one', message_two.correlations)
+        # self.assertIn('message_correlation_key_two', message_two.correlations)
+        # self.assertNotIn('message_correlation_key_two', message_one.correlations)