8c673c4fb6
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. |
||
---|---|---|
.github/workflows | ||
SpiffWorkflow | ||
bin | ||
bpmn-js-spiffworkflow | ||
connector-proxy-demo | ||
spiffworkflow-backend | ||
spiffworkflow-frontend | ||
.darglint | ||
.flake8 | ||
.gitignore | ||
.pre-commit-config.yaml | ||
.tool-versions | ||
LICENSE | ||
README.md | ||
docker-compose.yml | ||
poetry.lock | ||
pyproject.toml |
README.md
spiff-arena
SpiffArena is a low(ish)-code software development platform for building, running, and monitoring executable diagrams. It is intended to support Citizen Developers and to enhance their ability to contribute to the software development process. Using tools that look a lot like flow-charts and spreadsheets, it is possible to capture complex rules in a way that everyone in your organization can see, understand, and directly executable.
Please visit the SpiffWorkflow website for a Getting Started Guide to see how to run SpiffArena locally and try it out. There are also additional articles, videos, and tutorials about SpiffArena and its components, including SpiffWorkflow, Service Connectors, and BPMN.js extensions.
Contributing
This is a monorepo based on git subtrees that pulls together various spiffworkflow-related projects.
Feel free to ignore that and drop us a pull request.
If you need to push back from the monorepo to one of the individual repos, here's an example command (and find other scripts we use in the bin
directory):
git subtree push --prefix=spiffworkflow-frontend git@github.com:sartography/spiffworkflow-frontend.git add_md_file
Setup
poetry install
Run tests
./bin/run_pyl
Requires at root:
- .darglint
- .flake8
- .pre-commit-config.yaml
- pyproject.toml
License
SpiffArena's main components are published under the terms of the GNU Lesser General Public License (LGPL) Version 3.
Support
You can find us on our Discord Channel.
Commercial support for SpiffWorkflow is available from Sartography.