Zymonic:About

The Zymonic Workflow System

The Zymonic Workflow Framework is a collection of Perl modules and accompanying stylesheets, scripts etc. that allows an XML author to write a document describing processes (e.g. trouble- tickets, customer orders, course bookings, goods receiving, financial transactions - in fact just about anything) and to report on the information captured about those processes. Or, in extremely crude terms, it is a very sophisticated multi-user, web-based, database front-end.

For example an XML author might describe a support request or trouble ticket which has a number of stages; unconfirmed, confirmed, fix in progress, fixed - with each stage having limits about which stage can come next and what information needs to be captured from the user. The author can then describe reports based on the information captured.

Zymonic's processes can also be thought of as finite state machines.

Whilst there are a large number of frameworks that provide multi-user application development, some of which have a process model and some of which have a sophisticated security model we wrote Zymonic to have the following key features.

Key Features

• XML System Description, input and output - whilst there are undoubtedly downsides to using XML, the language is standards based and is easy for other systems to interface directly with (i.e. it has a native webservice for every process and report). The user interface (HTML) is then generated with XSL transforms.
• System entirely built from generic modules with two master modules (process and filter) - this allows maximum code re-use to minimise bugs.
• Zymonic is designed for PCI DSS compliance - the code is developed according to PCI DSS and the code is peer reviewed against PCI DSS and OWASP guidance - obviously this does not give either automatic guaranteed security or PCI compliance, however it does make both significantly easier.
• Zymonic has a security system which allows Access Control Lists to be set on each data record and for the defaults to be defined by a user or group's relationship with the record.
• Flexible reporting system.
• Multiple virtual desktops (or portals) for users; whilst some users can be provided with a small set of virtual desktops for the tasks they regularly do, power users can be given permission to create their own virtual desktops and assemble their own combinations of filters (reports) and processes.
• Accessibility - all features of Zymonic are available in a version of the interface which works with minimal javascript and complies with the Web Content Accessibility Guidelines (WCAG).
• Desktop application like speed and ease of use in the AJAX version of the interface.
• Compact XML definition that allows the re-use of 'objects' defined previously within the XML either with or without modifications. Plus the ability to flag tables with automatic maintenance process and filter generation - for a quick start.

Additional Features

• Actions such as generating reports or populating a secondary table e.g. a history table with data, can be triggered when a transition is successful.
• Advanced error reporting framework - securely reports errors to the appropriate person (DB admin, system admin, developers, XML author etc.) With a detailed log being available for collection.
• Detailed input validation (inc. anti-cross site scripting on all input) with clear highlighting of fields with errors and the error.
• Ability to define actions that can be triggered from filter output.
• Help integrated into the system definition for easy maintenance of user documentation.
• Modification collision detection and resolution (instead of 'hard-locking' records).
• Auto-documenting of API and interface.

Architecture and Concepts

• One of the key features of Zymonic is that everything is either a Process or Filter; activities that change data or interface with other systems are processes, then filters are reports on data within the system. The Field objects are common to both filters and processes - this means there is a massive amount of code re-use which makes achieving reliability and easy maintenance very straightforward.
• Processes are effectively state machines with Transitions and Conditions on Transitions defined in the XML.

Dynamic Module Selection

• Zymonic is capable of being extended with different Forms, Tables, Filters and Fields. However, not only can they simply be defined in XML, they can also be written as Perl modules or XML with some extra methods defined/overridden in Perl.
• This can be achieved by creating modules that are loaded either by the Registry handler or in the calling script e.g. creating and 'useing' a Zymonic::Form::invoice and then refering to an 'invoice' form in the XML will result in the Zymonic::Form::invoice module being used instead of the standard Zymonic::Form module.

Visit the Medoc website