What is Zymonic?
Introduction[edit]
Zymonic is a framework for building web-based, high-security (sufficient for PCI-DSS_ business applications). The systems that Zymonic produces use processes, and filter to interact with data in database tables.
The Architecture is as follows:
Let’s have a look at how they are produced using simple XML. Further information on everything mentioned can be found in later sections.
Here are some guidelines for writing Zymonic XML.
Files[edit]
Design Rules[edit]
- Each file should have a prefix to indicate the system, e.g. ebex_stock_movement_report.xml, ecommerce_tables.xml, pte_description.xml. This is to avoid conflicts if combining different moduless XML files.
- Each file's root element should be:
<ZymonicschemaVersion="1" maintainerEmailAddress="developers@zednax.com" xmlns="http://www.zymonic.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xh="http://www.w3.org/1999/xhtml" xsi:schemaLocation="http://www.zymonic.com https://www.zymonic.com/zymonic_config.xsd http://www.w3.org/1999/xhtml http://www.w3.org/2002/08/xhtml/xhtml1-strict.xsd"> <-- XML definitions go here --> </Zymonic>
- Each Process/Filter within a mode should have its own XML file. Each should also be given a category.
- All core field definitions (i.e. basic id, name, time, description, etc) that are generally used as bases should go in a single fields.xml
- All objects should be given a short description..
- Long description should be added where field usage is not trivial, i.e. not needed for name fields, is needed for expiry_date fields
The schema with all features (including those in development) can be found at : https://www.zymonic.com/zymonic_config.xsd - for live and QA schemas the URLs are : https://www.zymonic.com/live_zymonic_config.xsd and https://www.zymonic.com/qa_zymonic_config.xsd respectively. We generally make changes backwards compatible and therefore XML drafted to work with live or QA code should validate against the main (development) schema. However, if you are not a core developer and working with only the live version of Zymonic then we recommend working with the live schema to avoid inadvertently using features that are not available yet.
Suggested (but not yet confirmed) rules[edit]
- Each table should have its own file
- Fields in a table should all be based to have znames just for the table.
- Forms should have their own files, and all fields in it should be based on fields from the underlying table with new znames. Field groups should be added to the fields at this point.
- Each Process/Filter within a mode should have its own XML file. Each should also be given a category.
- All core field definitions (i.e. basic id, name, time, description, etc) that are generally used as bases should go in a single fields.xml
- All objects should be given a short description..
- Long description should be added where field usage is not trivial, i.e. not needed for name fields, is needed for expiry_date fields. Long description will be showed on the autogenerated manual
ZName[edit]
Zymonic objects are referenced using their ZName.
Though the ZName can be set to anything, it is easier for authors if the ZNames are set with the project in mind.
There is also a degree of inheritance in the naming convention.
eg
pte_p_payment_data
pte_ppd_s_entry
pte_ppd_s_entry Enter Payment Information, Capture required fields for Processing Payment
- pte is the project
- p defines the ZName as a process
- pte_ppd_s_entry - defines the project (pte), the process (_ppd) the state (_s) and the name (_entry)
_ppd comes from the process name pte_p_Payment_Data (the first letter of each word in the process)
This process would then be saved as ppd.xml
The User Interface (UI)[edit]
Zymonic URLs are generally of the form https://[domain]/zymonicmp/[system]/[page] the last thing is the ‘Page’.
On this ‘Page’ is a bar at the top and then one or more ‘Blocks’ each of which can contain a 'Filter' or a 'Process'.
If you open a new ‘Block’ on a ‘Page’ it stays there until you close it even if you navigate to a different ‘Page’
The top-bar of each ‘Page' has a list of other ‘Pages’ and user and utility functionality.
Some 'Pages' have a 'Block' that contains a 'Filter' that can show a list of other 'Filters' or 'Processes' - referred to as either 'menu' or ‘FoFaP’ - in the vast majority of cases that 'Block' is on the left.
Examples of Pages[edit]
This 'Queue Page' has a 'Filter' of 'SR's (a Process) and one 'SR' open.
This 'Triage Page' has a 'Menu' (on the left) and one 'Filter' (Service Requests List) open.
Processes[edit]
A process captures data from the user and enters it into a specified table in the database. It can be defined similarly to below:
<Process>
<ZName>heating_process</ZName>
<DisplayName>Heating Process</DisplayName>
<InitialState><ZName>cold</Zname></InitialState>
<Transition>
<ZName>switch_on</ZName>
<DisplayName>Switch ON</DisplayName>
<StateBefore><ZName>cold</ZName></StateBefore>
<StateAfter><ZName>getting_hotter</ZName></StateAfter>
</Transition>
<Transition>
<ZName>switch_off</ZName>
<DisplayName>Switch Off</DisplayName>
<StateBefore><ZName>getting_hotter</ZName></StateBefore>
<StateAfter><ZName>getting_colder</ZName></StateAfter>
</Transition>
<State>
<ZName>getting_hotter</ZName>
<Form>
<ZName>getting_hotter_form</ZName>
<Table><ZName>heating_table</ZName></Table>
<Field>
<ZName>temperature</ZName>
</Field>
<Field>
<ZName>average</ZName>
</Field>
<Field>
<ZName>date</ZName>
<FieldGroup>
<ZName>data</ZName>
<DisplayName>Data</DisplayName>
</FieldGroup>
</Field>
</Form>
</State>
<State>
<ZName>too_hot</ZName>
<Form>
<ZName>too_hot_form</ZName>
<Table><ZName>heating_table</ZName></Table>
<Field>
<ZName>temperature_sensor</ZName>
</Field>
</Form>
</State>
</Process>
The above XML would produce the following for the user:
Tables[edit]
Data captured by the process are entered into a database table also defined in the XML as follows:
<Table>
<ZName>heating_table</ZName>
<DisplayName>Heating</DisplayName>
<Field>
<ZName>temperature</ZName>
<Base>temperature</Base>
<DisplayName>Temperature</DisplayName>
</Field>
<Field sequence="1">
<ZName>average</ZName>
<Base>average</Base>
<RequiredField>true</RequiredField>
</Field>
<DefaultProcessZName>heating_process</DefaultProcessZName>
</Table>
Filters[edit]
A filter captures data from the user using search fields and reports back matching results from the database table using report fields. It can be defined similarly to below:
<Filter>
<ZName>heating_filter</ZName>
<DisplayName>Heating Filter</DisplayName>
<BaseTable>
<ZName>heating_table</ZName>
</BaseTable>
<ReportField>
<Field>
<ZName>temperature_rf</ZName>
</Field>
<SearchMap>
<Condition>ZZRF LIKE ?</Condition>
<PercentAfter>true</PercentAfter>
<PercentBefore>true</PercentBefore>
<SearchFieldName>temperature_sf</SearchFieldName>
<ZName>temperature_sm</ZName>
</SearchMap>
<ZName>cbos_profile_profile_tillno_field_rf</ZName>
</ReportField>
<ReportField>
<Field>
<ZName>average_rf</ZName>
</Field>
<SearchMap>
<Condition>ZZRF LIKE ?</Condition>
<PercentAfter>true</PercentAfter>
<PercentBefore>true</PercentBefore>
<SearchFieldName>average_sf</SearchFieldName>
<ZName>average_sm</ZName>
</SearchMap>
</ReportField>
</Filter>
The above XML would produce the following to the user:
Putting it all together[edit]
A final site might have these separate elements on one page, with multiple filters and processes that can be opened from the menu on the left (the menu is also a filter). Also note that contents XML files must be wrapped in <Zymonic></Zymonic> tags or they won't be included in Zymonic.