spiff-arena/tests/SpiffWorkflow/spiff/CorrelationTest.py

60 lines
2.7 KiB
Python
Raw Normal View History

from SpiffWorkflow.bpmn.workflow import BpmnWorkflow
from .BaseTestCase import BaseTestCase
class CorrelationTest(BaseTestCase):
def testMessagePayload(self):
self.actual_test(False)
def testMessagePayloadSaveRestore(self):
self.actual_test(True)
def actual_test(self,save_restore):
specs = self.get_all_specs('correlation.bpmn')
proc_1 = specs['proc_1']
self.workflow = BpmnWorkflow(proc_1, specs)
if save_restore:
self.save_restore()
self.workflow.do_engine_steps()
# Set up some data to evaluate the payload expression against
for idx, task in enumerate(self.workflow.get_ready_user_tasks()):
task.data['task_num'] = idx
task.data['task_name'] = f'subprocess {idx}'
task.data['extra_data'] = f'unused data'
task.complete()
self.workflow.do_engine_steps()
ready_tasks = self.workflow.get_ready_user_tasks()
for task in ready_tasks:
self.assertEqual(task.task_spec.name, 'prepare_response')
response = 'OK' if task.data['source_task']['num'] else 'No'
task.data.update(response=response)
task.complete()
self.workflow.do_engine_steps()
# If the messages were routed properly, the task number should match the response id
for task in self.workflow.get_tasks_from_spec_name('subprocess_end'):
self.assertEqual(task.data['response']['init_id'], task.data['task_num'])
self.assertEqual(task.data['response']['response'], 'OK' if task.data['task_num'] else 'No')
class DualConversationTest(BaseTestCase):
def testTwoCorrelatonKeys(self):
spec, subprocesses = self.load_workflow_spec('correlation_two_conversations.bpmn', 'message_send_process')
workflow = BpmnWorkflow(spec, subprocesses)
workflow.do_engine_steps()
messages = workflow.get_bpmn_messages()
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]
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
2023-02-27 14:59:36 -05:00
# 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)