The ZIAgent back end runs as a web site. It communicates with ZIServer using standard Internet protocols (HTTP or HTTPS)  and formats defined in the specifications created for the industry. For education, this the SIF specification; for healthcare, , while other industries may have their own standardized specifications. In other cases, specifications may have been developed to meet a particular need.

ZIAgent supports several security and authentication models including all those listed in the specifications. We have also extended these models to reflect recommendations from the OWASP 2017 Top 10 list. See OWASP (pdf) for more information.

When ZIAgent is at the beginning of the configuration process, it already knows about every element and every attribute of every object defined in the specification to be used (this was set up beforehand). In its configuration database, it has tables that contain staging areas for incoming data, validation tables for all possible legal

Publishers are applications that store information to be shared with other applications in a particular zone. Student management systems are typical examples of publishers. Many applications that mostly subscribe may also publish as well. For example, a transportation system may subscribe to student and workforce information, but it may also publish bus stop and route information.

Agents for publishing applications are configured through a simple two-step process using the ZIAgent designer. The first step involves specifying where the data can be found in the application’s database. The second step consists of mapping each of the application’s fields to corresponding standardized fields and determining if there should be translations set up for it.

	Target Database Discovery When configuring an object for publication, the ZIAgent designer asks for a statement that “requests all records” for the object being configured. With the results of that query, it takes whatever information it can (types, sizes, locations, etc.) and uses that information to build internal tables. These tables are used in other parts of the designer for validation checks to automate the process wherever possible or to make the process as error-free as possible. Note If you look at the data shown in this example, there are two things to point out: The names of the columns and the encoded field values in the application database do not need to match the definitions in the standard. ZIAgent handles mapping these names and values. Student information used in these screen captures are for fictional student records randomly created from lists of popular last and first names. Any resemblance to real persons, living or dead, is purely coincidental.
	Object Field Mapping Once the designer has learned as much as it can from looking at the sample data, it presents a simple screen to the user, allowing him or her to select the fields from the SQL statement that match the XML field in the message to be transferred. If the data element (or attribute) represents an encoded value, the last column will contain a “configuration” icon indicating that translations should be set up for this element or attribute. Clicking this icon brings the user to the next screen.
	Automatic Translation Discovery If an application gives its users an ability to define or extend code value sets, then whenever the application is installed somewhere new, these new code values need to be mapped to the values defined by the standard. To address this common problem, we added a feature that searches for any values that may have been added locally by a customer. If any of these values need have a translation, the application alerts the user.

Subscribing agents are configured by defining rules that are triggered on receipt of either an “Add”, “Change” or ”Delete” event. These same rules are reused when a response is received. In this case, the agent decides if it is proper to use the “Add” or “Change” rule depending on whether or not the object has been “seen” by the adapter already. There is a fourth rule type: “SYNC” – this rule type is executed for both “Add” and “Change” events.

	Event Rules Overview In the following examples, we will use some examples from an education example that uses the SIF specification from the A4L organization. In this screen, we see a summary of the event rules defined for the StudentSchoolEnrollment object for a subscribing application agent. Five of the rules are defined to handle incoming “Add” events and another three to handle “Change” events. Although it would be possible, this agent is not configured to handle “Delete” events. To see the details for one of the rules, the user clicks on the ‘Edit’ button.
	Event Rules – Dynamic Matching This is an example of a Dynamic Matching rule. Some subscribing applications have multiple sources of input, including interactive user input. This rule tells the adapter to search the application database (using the supplied matching criteria) before adding a new record to see if there might already be a record that was created through another interface. If the same record was already added, the ‘Add’ event is turned into a ‘Change’ event, and the two records are synchronized. This avoids the possibility of creating duplicate records. Multiple DMATCH rules may be created for the same object using different matching patterns.
	Event Rule – Add Event This example is also an ‘Add’ event. It combines information from several objects, adds information from the environment and passes the information to a CEDS Data Warehouse that is housed in an Oracle environment on another server. Only the records that have passed all of the validation checks in rules 20, 30 and 40 will update the Oracle DW. The records that fail validation will be set aside for alternative processing.

In addition to sending information to target applications using a variety of methods, ZIAgent also provides a number of other unique features:

• Error Handling – ZIAgent provides extensive support for error handling, depending on the needs of the application. Some subscribing applications choose to only allow the agent to pass “clean” data from the input stream to it and send “less than clean” data to a “suspense” location. Others configure the rules so that all data is forwarded from the agent to the applications, allowing it to handle errors.. Some others are in-between. ZIAgent has the flexibility to support them all.
• Self-healing Rules – These rules are written in a way that detects when something wrong has occurred, and they trigger other events to correct the problem and cause theto be repeated. For example, let’s say that in education, a StudentSchoolEnrollment (student enrollment in a school) event was received by an adapter, but it never received a StudentPersonal (student demographics) record for one of the students. The rule can make a request for the missing StudentPersonal record, exit, and then have the student’s complete record processed later after the StudentPersonal event  has been received.
• Email Notifications – These can be attached to any rule (event or business rule) to notify someone that immediate attention is needed.