General Description

The ZIS-System is a monitoring unit that allows a user to apply rules on occurring events. These rules allow the ZIS-System to forward it to Valuemation “I / P / C”. If this event cannot be related to a ticket within Valuemation a new ticket will be created whereas an already existing ticket will be updated accordingly.

The data sent to Valuemation respectively to the EPI has a specific structure based on the transaction and its required set of parameter. The structure has to be parsed and validated by the receiving system in order to dispatch, enrich or just directly process it.

In case an event has triggered a transaction in order to create or update a ticket, a structured message has to be sent to the EPI by making use of the ZEXEC protocol. This also happens if the event will be deleted from within the unit the event resides.

When ZIS reports a new incident there can be two actions that will take place:

• A user responsible for the reported incident gets informed via SMS or phone call

• A message is to be sent to the EPI via Zexec

In the EPI there is a listener running in the background which uses a free port. That listener reacts instantly to incoming messages without causing a noteworthy delay. This is important because a user of Valuemation shall notice an incident as soon as it occurs (almost in real-time).

Workflows within the context of the EPI

A new message that has been received from the EPI via Zexec will cause creating a new entry in the EPI-database. At the same time the Process Manager of the EPI will induce a transfer of the new message data to an extra transfer table (intermediate table) of Valuemation. This means that there is at least one additional table which holds all data that has been sent from ZIS via the EPI. The creation respectively the update of a ticket in Valuemation will take place by workflows that have to be created in Valuemation. These workflows become initiated by the escalation server. The same principle is already implemented in the communication server for the inbound-email-system. By doing it this way there is the big advantage that all internal functionalities of Valuemation remain inside of Valuemation and thus they do not have to become programmed anew in another environment.

For the purpose of exchanging data between ZIS and the EPI there are some additional tables within the EPI-database specially created for the transfer. Therefore it would also be a practicable solution sending not only an unique ZIS_REFERENCE_ID (from ZIS to EPI) as the sole content of the message within the plain textfile (this has been done in the prototype), but also the other ticketing relevant data should be included in the message-file that ZIS generates. Then in EPI a rule has to be deposited which determines under what circumstances a reported incident shall cause creating a ticket respectively update an existing ticket in any way.

Rule

Put all necessary information of ZIS into the message sent to the EPI (plain textfile), not only the ZIS_REFERENCE_ID. Background: ZIS is a running system and it does not write all relevant data instantly to its connected database. Some data is only available in the cache. So ZIS can provide all information during runtime by writing it into a file. Only connecting to the ZIS database will not prove to be sufficient.

If a rule deposited in the EPI determines that something is to send to Valuemation, the EPI will write that information in form of sensible value-pairs into the Valuemation transfer table. In case that one attribute should not have been delivered by ZIS there have to be wise default-values in available in EPI, e.g. a ticket description for creating a new ticket is missing: then insert a standard text.

In order to keep the extra work for individually customizing the EPI for each customer in a sensible range, it is planned to offer some kind of default rule for every kind of transaction. That is to say that we want to orientate the rules to be implemented by basic policies which finally result from heuristic experience. More details on that have to be coordinated with the expert of EMDS (EPI).

For the purpose of realizing a flexible ZIS-integration it is recommended to create some more Main Parameters within Valuemation, e.g. a default username representing the ZIS-System (“ZIS_System”), a default Ticket Class for an event in ZIS (“Incident”) and a reserved User ID for the ZIS-System.

Creating some new Main Parameters for ZIS is recommended for offering flexibility

When a ticket has been created induced by the EPI (and indirectly by the ZIS-System) the unique “ZIS_Reference_ID” will be added to that ticket. This is also crucial for every feedback signal that Valuemation sends to ZIS via the EPI. When a ticket has been updated caused by ZIS, then a corresponding flag will be set which indicates that there is some data that is determined for sending back to the ZIS-System. The other option is to abandon the idea of setting a special flag and to look for the current events and their connected tickets. Another aspect is to care for an automatism that cleans up the transfer table. Every data record that is not needed anymore should be deleted. For the initial implementation it will be sufficient considering a time factor, e.g. every entry older than a month gets deleted.

The EPI polls the Valuemation transfer tables in regular intervals and looks for all entries which have their flag set to “return” or something alike. In such a case, the EPI will send the corresponding Ticket ID and the current Status via Zexec to ZIS and having fulfilled that task, finally setting back the flags (e.g. from “return” to “done”). When a user in Valuemation changes the status of a ticket (see the following sections) that has been generated by the ZIS-System the new status has to be transferred to ZIS, so that an event unit which is connected to such a ticket might change its colour (indicates the current status). In ZIS the name of the status becomes determined according to the customer’s request. This is also true for the colour of such a status. It is common to let the customer decide about these issues. Yet it should be okay to set wisely chosen default values in ZIS. (must also be free / available values)

When ZIS induces the creation of a new ticket at the same time a responsible person will be informed about the new incident. If that person acknowledges this incident by giving a response via phone, email or SMS a new Ticket Description (“Alaram was acknowledged by XY”) has to be added to the corresponding Ticket. This would be an “update” action where the associated ticket becomes identified by the already existing ZIS_Reference_ID.