Background

Zymonic is the new name for Scat the web based Trouble Ticketing or Service Request application with ACL style security.

Scat v3 has been modified to provide enforced process flow, integration with subversion and timesheet generation for all project staff.

Scat v4 was redesigned from the ground up to be able a system to be built from an XML definition and create webservices which can be transformed with XSL to produce traditional web based views or used in raw XML form with other applications. Scat v4 also includes process design and management as part of its basic functionality.

Scat v4 is to become Zymonic the project and enterprise management suite. It is currently in final test. Zymonic the framework will be released under Alfresco license*, with a Creative Commons licensed trouble ticketing XML definition. Full project flows will be able to  be purchased off the shelf or designed specifically for your organsiation.

* If you wish to use portions of Zymonic in another open-source application, let us know and we may be able to release the portion under an alternative license (e.g. GPL)

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 minima  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. * 

* due shortly/not complete.

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. 

 * The exceptions being Pages and Blocks for the UI.

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 of the Zymonic::Form::invoice module being used instead of the standard Zymonic::Form module.