Products

ZIAgent

ZIAgent — Configurable Application Adapter

ZIA­gent changes the rules in enabling exist­ing appli­ca­tions to com­mu­ni­cate with oth­er appli­ca­tions. In gen­er­al, appli­ca­tions are either built with inter­op­er­abil­i­ty fea­tures as part of their inte­gral design or need an adapter to allow them to par­tic­i­pate in a com­mu­ni­ty of con­nect­ed appli­ca­tions.

Some appli­ca­tion mak­ers who need­ed adapters have gone the expen­sive and time-con­sum­ing route of hand-writ­ing their own using a toolk­it. Many oth­ers, how­ev­er, have cho­sen ZIA­gent, a con­fig­urable adapter, that takes advan­tage of exist­ing facil­i­ties that an appli­ca­tion has already, with­out requir­ing changes to the appli­ca­tion itself.

Instead of tak­ing weeks or months to devel­op and test, users can cre­ate deploy­able adapters with ZIA­gent in a mat­ter of hours or days, depend­ing on the com­plex­i­ty of the appli­ca­tion and the amount of infor­ma­tion being exchanged.

Lev­el of exper­tise required? Typ­i­cal­ly, if you can build SQL queries, you can con­fig­ure an appli­ca­tion adapter with ZIA­gent.

The Interoperability Challenge

The "inter­op­er­abil­i­ty chal­lenge" has been addressed in the past, but wher­ev­er and when­ev­er it was approached, very sim­i­lar steps were tak­en: It start­ed with mak­ing design changes in the appli­ca­tion, writ­ing new code, test­ing the code, find­ing out that extra lev­els of secu­ri­ty are need­ed (because the con­nect­ed com­mu­ni­ty is larg­er), then imple­ment­ing and test­ing the extra lev­els of secu­ri­ty, etc.

With an Agent (Adapter) Devel­op­ment Kit, even though some of the pieces may have been built for you, the agent must still be built, debugged and test­ed. One of our cus­tomers who had expe­ri­ence with both described it this way: "It's like build­ing a house: even though some of the pieces come ready-built, most of the work still needs to be done. For exam­ple, house builders may use pre-fab­ri­cat­ed truss (roof) sys­tems and fur­naces, but they still need to pour the foun­da­tion, build the walls, run the plumb­ing, elec­tri­cal, etc."

ZIA­gent was first built back in 2001 and has been in a process of being refined ever since. In our customer's anal­o­gy, it's the fin­ished house — ready to con­fig­ure (dec­o­rate) and use (move in). Because of the way we designed ZIA­gent, we don't rebuild every new adapter from the begin­ning or almost the begin­ning (as you would even with the best ADK). As a result, we've been able to spend many years mak­ing it more:

  • Scal­able — Deploy­ments can be installed eas­i­ly on a sin­gle serv­er or across sev­er­al servers to sup­port large host­ed envi­ron­ments with many cus­tomers.
  • Flex­i­ble — Agents can sup­port appli­ca­tions that use almost every com­mer­cial­ly avail­able data­base through a vari­ety of inter­faces.
  • Reli­able — We've had years' of expe­ri­ence see­ing what can hap­pen in the field, so we have built detec­tion and recov­ery pro­ce­dures into ZIA­gent. Com­pa­nies who build agents using an ADK will like­ly gain this expe­ri­ence through tri­al and error.
  • Secure — ZIA­gent has many built-in fea­tures for data secu­ri­ty and pri­va­cy that have come from cus­tomer requests over the years such as mes­sage audit­ing, record fil­ter­ing and activ­i­ty log­ging.
  • Sup­port­ed — ZIA­gent was first released in 2001, and we've been refin­ing it ever since. We are con­tin­u­al­ly adding new fea­tures, enhanc­ing the run­time engine and improv­ing the user inter­face.

Microsoft Com­mer­cial App Cer­ti­fi­ca­tion is a val­i­da­tion ser­vice for cloud and on-premise appli­ca­tions built-on or inte­grat­ed with com­mer­cial Microsoft tech­nolo­gies such as Azure, SQL Serv­er, Win­dows Serv­er and oth­ers. Cer­ti­fi­ca­tion logo badges give buy­ers con­fi­dence that this solu­tion is:

    • Ful­ly com­pat­i­ble with Microsoft tech­nolo­gies Cer­ti­fi­ca­tion tests val­i­date that the solu­tion fol­lows cod­ing prin­ci­ples and inte­grates seam­less­ly with Microsoft tech­nolo­gies.
    • Man­aged by a trust­ed part­ner Cer­ti­fied solu­tions are cre­at­ed and sup­port­ed by val­i­dat­ed and trust­wor­thy part­ners.

Certified for Windows Server 2019

ZIA­gent is cer­ti­fied by Microsoft to run reli­ably on the Win­dows Serv­er 2019 plat­form and inte­grate seam­less­ly with oth­er Microsoft tech­nolo­gies.

Microsoft Com­mer­cial App Cer­ti­fi­ca­tion is a val­i­da­tion ser­vice for cloud and on-premise appli­ca­tions built-on or inte­grat­ed with com­mer­cial Microsoft tech­nolo­gies such as Azure, SQL Serv­er, Win­dows Serv­er and oth­ers. Cer­ti­fi­ca­tion logo badges give buy­ers con­fi­dence that this solu­tion is:

  • Ful­ly com­pat­i­ble with Microsoft tech­nolo­gies Cer­ti­fi­ca­tion tests val­i­date that the solu­tion fol­lows cod­ing prin­ci­ples and inte­grates seam­less­ly with Microsoft tech­nolo­gies.
  • Man­aged by a trust­ed part­ner Cer­ti­fied solu­tions are cre­at­ed and sup­port­ed by val­i­dat­ed and trust­wor­thy part­ners.

Certified for Windows Server 2016

ZIA­gent is cer­ti­fied by Microsoft to run reli­ably on the Win­dows Serv­er 2016 plat­form and inte­grate seam­less­ly with oth­er Microsoft tech­nolo­gies.

How it Works

The ZIA­gent back end runs as a web site. It com­mu­ni­cates with ZIS­erv­er using stan­dard Inter­net pro­to­cols (HTTP or HTTPS) and for­mats defined in the spec­i­fi­ca­tions cre­at­ed for the indus­try. For edu­ca­tion, this the SIF spec­i­fi­ca­tion; for health­care, , while oth­er indus­tries may have their own stan­dard­ized spec­i­fi­ca­tions. In oth­er cas­es, spec­i­fi­ca­tions may have been devel­oped to meet a par­tic­u­lar need.

ZIA­gent sup­ports sev­er­al secu­ri­ty and authen­ti­ca­tion mod­els includ­ing all those list­ed in the spec­i­fi­ca­tions. We have also extend­ed these mod­els to reflect rec­om­men­da­tions from the OWASP 2017 Top 10 list. See OWASP (pdf) for more infor­ma­tion.

When ZIA­gent is at the begin­ning of the con­fig­u­ra­tion process, it already knows about every ele­ment and every attribute of every object defined in the spec­i­fi­ca­tion to be used (this was set up before­hand). In its con­fig­u­ra­tion data­base, it has tables that con­tain stag­ing areas for incom­ing data, val­i­da­tion tables for all pos­si­ble legal

Infor­ma­tion Shar­ing Appli­ca­tions — Pub­lish­ers

Pub­lish­ers are appli­ca­tions that store infor­ma­tion to be shared with oth­er appli­ca­tions in a par­tic­u­lar zone. Stu­dent man­age­ment sys­tems are typ­i­cal exam­ples of pub­lish­ers. Many appli­ca­tions that most­ly sub­scribe may also pub­lish as well. For exam­ple, a trans­porta­tion sys­tem may sub­scribe to stu­dent and work­force infor­ma­tion, but it may also pub­lish bus stop and route infor­ma­tion.

Agents for pub­lish­ing appli­ca­tions are con­fig­ured through a sim­ple two-step process using the ZIA­gent design­er. The first step involves spec­i­fy­ing where the data can be found in the application’s data­base. The sec­ond step con­sists of map­ping each of the application’s fields to cor­re­spond­ing SIF fields and deter­min­ing if there should be trans­la­tions set up for it.

Target Database Discovery

When con­fig­ur­ing an object for pub­li­ca­tion, the ZIA­gent design­er asks for a state­ment that “requests all records” for the object being con­fig­ured. With the results of that query, it takes what­ev­er infor­ma­tion it can (types, sizes, loca­tions, etc.) and uses that infor­ma­tion to build inter­nal tables.

These tables are used in oth­er parts of the design­er for val­i­da­tion checks to auto­mate the process wher­ev­er pos­si­ble or to make the process as error-free as pos­si­ble.

Note
If you look at the data shown in this exam­ple, there are two things to point out:
  • The names of the columns and the encod­ed field val­ues in the appli­ca­tion data­base do not need to match the def­i­n­i­tions in the stan­dard. ZIA­gent han­dles map­ping these names and val­ues.
  • Stu­dent infor­ma­tion used in these screen cap­tures are for fic­tion­al stu­dent records ran­dom­ly cre­at­ed from lists of pop­u­lar last and first names. Any resem­blance to real per­sons, liv­ing or dead, is pure­ly coin­ci­den­tal.

Object Field Mapping

Once the design­er has learned as much as it can from look­ing at the sam­ple data, it presents a sim­ple screen to the user, allow­ing him or her to select the fields from the SQL state­ment that match the XML field in the mes­sage to be trans­ferred.

If the data ele­ment (or attribute) rep­re­sents an encod­ed val­ue, the last col­umn will con­tain a “con­fig­u­ra­tion” icon indi­cat­ing that trans­la­tions should be set up for this ele­ment or attribute. Click­ing this icon brings the user to the next screen.

Automatic Translation Discovery

If an appli­ca­tion gives its users an abil­i­ty to define or extend code val­ue sets, then when­ev­er the appli­ca­tion is installed some­where new, these new code val­ues need to be mapped to the val­ues defined by the stan­dard.

To address this com­mon prob­lem, we added a fea­ture that search­es for any val­ues that may have been added local­ly by a cus­tomer. If any of these val­ues need have a trans­la­tion, the appli­ca­tion alerts the user.

Infor­ma­tion Sub­scrib­ing Appli­ca­tions

Sub­scrib­ing agents are con­fig­ured by defin­ing rules that are trig­gered 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 prop­er to use the “Add” or “Change” rule depend­ing on whether or not the object has been “seen” by the adapter already. There is a fourth rule type: “SYNC” – this rule type is exe­cut­ed for both “Add” and “Change” events.

Event Rules Overview

In the fol­low­ing exam­ples, we will use some exam­ples from an edu­ca­tion exam­ple that uses the SIF spec­i­fi­ca­tion from the A4L orga­ni­za­tion.

In this screen, we see a sum­ma­ry of the event rules defined for the Stu­dentSchoolEn­roll­ment object for a sub­scrib­ing appli­ca­tion SIF agent.

Five of the rules are defined to han­dle incom­ing "Add” events and anoth­er three to han­dle "Change” events. Although it would be pos­si­ble, this agent is not con­fig­ured to han­dle "Delete” events. To see the details for one of the rules, the user clicks on the ‘Edit’ but­ton.

Event Rules — Dynamic Matching

This is an exam­ple of a Dynam­ic Match­ing rule. Some sub­scrib­ing appli­ca­tions have mul­ti­ple sources of input, includ­ing inter­ac­tive user input.

This rule tells the adapter to search the appli­ca­tion data­base (using the sup­plied match­ing cri­te­ria) before adding a new record to see if there might already be a record that was cre­at­ed through anoth­er inter­face. If the same record was already added, the ‘Add’ event is turned into a ‘Change’ event, and the two records are syn­chro­nized. This avoids the pos­si­bil­i­ty of cre­at­ing dupli­cate records.

Mul­ti­ple DMATCH rules may be cre­at­ed for the same object using dif­fer­ent match­ing pat­terns.

Event Rule — Add Event

This exam­ple is also an ‘Add’ event.

It com­bines infor­ma­tion from sev­er­al objects, adds infor­ma­tion from the envi­ron­ment and pass­es the infor­ma­tion to a CEDS Data Ware­house that is housed in an Ora­cle envi­ron­ment on anoth­er serv­er.

Only the records that have passed all of the val­i­da­tion checks in rules 20, 30 and 40 will update the Ora­cle DW. The records that fail val­i­da­tion will be set aside for alter­na­tive pro­cess­ing.

In addi­tion to send­ing infor­ma­tion to tar­get appli­ca­tions using a vari­ety of meth­ods, ZIA­gent also pro­vides a num­ber of oth­er unique fea­tures:

  • Error Han­dling — ZIA­gent pro­vides exten­sive sup­port for error han­dling, depend­ing on the needs of the appli­ca­tion. Some sub­scrib­ing appli­ca­tions choose to only allow the agent to pass “clean” data from the input stream to it and send “less than clean” data to a “sus­pense” loca­tion. Oth­ers con­fig­ure the rules so that all data is for­ward­ed from the agent to the appli­ca­tions, allow­ing it to han­dle errors.. Some oth­ers are in-between. ZIA­gent has the flex­i­bil­i­ty to sup­port them all.
  • Self-heal­ing Rules — These rules are writ­ten in a way that detects when some­thing wrong has occurred, and they trig­ger oth­er events to cor­rect the prob­lem and cause theto be repeat­ed. For exam­ple, let’s say that in edu­ca­tion, a Stu­dentSchoolEn­roll­ment (stu­dent enroll­ment in a school) event was received by an adapter, but it nev­er received a Stu­dent­Per­son­al (stu­dent demo­graph­ics) record for one of the stu­dents. The rule can make a request for the miss­ing Stu­dent­Per­son­al record, exit, and then have the student’s com­plete record processed lat­er after the Stu­dent­Per­son­al event has been received.
  • Email Noti­fi­ca­tions — These can be attached to any rule (event or busi­ness rule) to noti­fy some­one that imme­di­ate atten­tion is need­ed.

Com­mon Fea­tures

Many appli­ca­tions behave as both pub­lish­ers and sub­scribers. ZIA­gent sup­ports these more com­plex con­fig­u­ra­tions as well as the fea­tures that are com­mon to all appli­ca­tions that use the adapter:

  • Import/Export — Once a con­fig­u­ra­tion is com­plet­ed, it may be export­ed and saved to an XML file. This allows us to migrate a con­fig­u­ra­tion from one stan­dard XML ver­sion (SIF, HL7, or oth­er) to the next. The migra­tion process gen­er­al­ly involves export­ing from the old ver­sion and import­ing to the new ver­sion. It also elim­i­nates the need for data­base back­ups and when deploy­ing ZIA­gent to mul­ti­ple loca­tions.
  • Busi­ness Rules — Busi­ness rules are much like event rules, except that they are not asso­ci­at­ed with any par­tic­u­lar event. Busi­ness rules may be run on demand (from the agent dash­board) or may be sched­uled to be run at pre­scribed inter­vals.
  • Web Ser­vice Call Audit­ing — Sim­i­lar to the XML Mes­sage Ledger, ZIA­gent also stores a Web Ser­vice Call Ledger that keeps track of any calls that the agent made to an exter­nal web ser­vice. This includes infor­ma­tion passed to or returned from it, as well as the time it took to com­plete the action.

Message Auditing

ZIA­gent keeps track of its mes­sage activ­i­ty in a mes­sage ledger and presents it through a search­able, sortable user inter­face.

This mes­sage ledger keeps track of when the mes­sage was sent, any errors returned by ZIS­erv­er, the agent it was sent to, and a drill-down fea­ture that allows the user to view the con­tents.

Rule Tracing

While devel­op­ing or trou­bleshoot­ing an agent, trac­ing can be turned on through the admin­is­tra­tion pan­el. This caus­es it to main­tain a lim­it­ed set of “rolling log­files” that store, on a very detailed lev­el, what the agent is doing inter­nal­ly.

This allows sup­port staff to eas­i­ly track down issues with the agent’s con­fig­u­ra­tion or pos­si­bly with data it is receiv­ing from oth­er agents.

Licens­ing

We offer sev­er­al licens­ing mod­els that vary depend­ing on dif­fer­ing needs.

Type of User License Includes License Char­ac­ter­is­tics
Appli­ca­tion Sup­pli­er (Ven­dor)
  • ZIA­gent Design­er
  • ZIA­gent Run­time
  • Licensed for supplier’s appli­ca­tion
  • No run­time roy­al­ties
  • Includes new ver­sions
  • Includes 20 hours of Tier 2 sup­port dur­ing the first 6 months (Stan­dard Edi­tion) or unlim­it­ed Tier 2 sup­port dur­ing the first year (Plat­inum Edi­tion) to help you with your first agent deploy­ments
  • VSI devel­op­er spends time with supplier’s staff, con­fig­ures agent and runs through SIF cer­ti­fi­ca­tion process.
Munic­i­pal­i­ty, School Dis­trict, oth­er School Orga­ni­za­tion, or Cor­po­rate Enti­ty with many loca­tions
  • ZIA­gent Design­er
  • ZIA­gent Run­time
  • Licensed for all appli­ca­tions devel­oped by orga­ni­za­tion staff
  • No run­time roy­al­ties – may be installed and used any­where in the orga­ni­za­tion
  • Includes new ver­sions
  • VSI devel­op­ers pro­vide train­ing to organization’s staff on how to con­fig­ure SIF agents. Devel­op­ers use one or two appli­ca­tions from the school orga­ni­za­tion dur­ing the train­ing ses­sion so that the school staff has use­ful, work­ing exam­ples at the end of the ses­sion.
Munic­i­pal­i­ty, School Dis­trict, oth­er School Orga­ni­za­tion, or Cor­po­rate Enti­ty with many loca­tions
  • ZIA­gent Run­time
  • Licensed per school for the pur­pose of run­ning pub­licly avail­able con­fig­u­ra­tion sets
  • Includes new ver­sions
Sys­tems Inte­gra­tor
  • ZIA­gent Design­er
  • VSI devel­op­ers pro­vide in-depth train­ing on how to con­fig­ure agents
  • Roy­al­ty paid per instal­la­tion for each agent con­fig­ured
Region­al, State or Nation­al Orga­ni­za­tion or Edu­ca­tion Office
  • ZIA­gent Design­er
  • ZIA­gent Run­time
  • Region or state-wide license avail­able for all non-com­mer­cial appli­ca­tions
  • No run­time roy­al­ties
  • VSI pro­vides Region­al or State office staff train­ing and pro­vides class­room train­ing to mem­ber orga­ni­za­tions.

ZIServer

ZIServer — High-Speed Message Broker

At the foun­da­tion of any inter­op­er­abil­i­ty envi­ron­ment is a mes­sage bro­ker. It is soft­ware, the invis­i­ble couri­er, that reli­ably deliv­ers infor­ma­tion from one source to one or more des­ti­na­tions. This is not done blind­ly, since the soft­ware is aware of the infor­ma­tion objects that are of inter­est to the var­i­ous appli­ca­tions. It is also aware of what the appli­ca­tions send and receive as well as the secu­ri­ty require­ments of each application's con­nec­tions.

Trans­lat­ing this aware­ness into enforced poli­cies, pro­vides secure and reli­able mes­sage bro­ker ser­vices.

ZIS­erv­er is…

Secure / Pri­vate

ZIS­erv­er sup­ports mul­ti­ple lev­els of net­work secu­ri­ty to make sure that any data trans­ferred across the Inter­net is done so safe­ly. In addi­tion to all lev­els required by the SIF edu­ca­tion spec­i­fi­ca­tion, we have added in sup­port for items list­ed in the OWASP Top 10.

With respect to pri­va­cy, one serv­er sup­ports mul­ti­ple zones, the num­ber of which is lim­it­ed only by the mem­o­ry and disk space avail­able on the serv­er. In addi­tion, ZIS­erv­er sup­ports clus­ters of zones which can be inde­pen­dent­ly admin­is­tered, so it is suit­able for state or oth­er region­al imple­men­ta­tions. For each of the zones, ZIS­erv­er pro­vides mul­ti­ple lev­els of pri­va­cy includ­ing

Learn More

Scal­able

One serv­er sup­ports mul­ti­ple zones, the num­ber of which is lim­it­ed only by the mem­o­ry and disk space avail­able on the serv­er. In addi­tion, ZIS­erv­er sup­ports clus­ters of zones which can be inde­pen­dent­ly admin­is­tered, suit­able for state, nation­wide or oth­er region­al imple­men­ta­tions.

ZIS­erv­er pro­vides web-based admin­is­tra­tion and man­age­ment with sep­a­rate roles for (all capa­bil­i­ties in all zones), Zone Admin­is­tra­tors (most capa­bil­i­ties for spec­i­fied zones) and Agent View­ers (lim­it­ed capa­bil­i­ties for spec­i­fied agents).

Learn More

High­ly Avail­able

ZIS­erv­er may be deployed as a high-avail­abil­i­ty serv­er farm on as many servers as need­ed in sin­gle or mul­ti­ple loca­tion (dis­as­ter recov­ery) con­fig­u­ra­tions.

It sup­ports SQL Serv­er AlwaysOn Avail­abil­i­ty Groups in local and dis­trib­uted con­fig­u­ra­tions, so that the data­base can be dupli­cat­ed in real-time and avail­able as a "hot spare" should a serv­er become unavail­able.

ZIS­erv­er sup­ports inbound load bal­anc­ing using either hard­ware or Win­dows Net­work Load Bal­anc­ing and imple­ments out­bound load bal­anc­ing, includ­ing auto­mat­ic sup­port for failover and recov­ery.

Learn More

Flex­i­ble

ZIS­erv­er sup­ports PULL (polled) and PUSH (real-time) events as well as request/response modes. It can be host­ed by a ser­vice provider or installed on-premise. A sin­gle imple­men­ta­tion can host many inde­pen­dent groups of appli­ca­tions (zones), each of which is iso­lat­ed from the oth­ers.

A sin­gle serv­er (or clus­ter of servers) sup­ports mul­ti­ple zones (groups of asso­ci­at­ed appli­ca­tions). The num­ber of these is lim­it­ed only by the mem­o­ry and disk space avail­able on the serv­er.

In the edu­ca­tion mar­ket, a com­mon inter­op­er­abil­i­ty stan­dard already exists, and many appli­ca­tions already con­form to it. ZIS­erv­er has the abil­i­ty to con­nect to any of these appli­ca­tions through a sim­ple con­fig­u­ra­tion process.

Learn More

High-Per­for­mance

Since 2001, Visu­al Soft­ware has been con­tin­u­al­ly refin­ing the ZIS­erv­er back end, mak­ing it faster, more secure, more effi­cient, more flex­i­ble and more reli­able.

With our cur­rent release and mod­est hard­ware, ZIS­erv­er can main­tain traf­fic loads even with mil­lions of com­plex mes­sages being passed per hour over secure con­nec­tions to many (dozens to thou­sands of) con­nec­tions simul­ta­ne­ous­ly.

Learn More

Auditable

ZIS­erv­er pro­vides user log­ging, detailed trac­ing and full mes­sage audit­ing capa­bil­i­ties. ZIS­erv­er also has the abil­i­ty to move old­er mes­sages into to archive data­bas­es, so that these can be stored on less expen­sive stor­age and be put onto a sep­a­rate back­up sched­ule.

Learn More

The User Inter­face

The ZIServer Dashboard

The ZIS­erv­er dash­board gives admin­is­tra­tors a quick overview of the health of the ZIS, how busy it has been late­ly, how the tun­able para­me­ters are set and, in gen­er­al, how servers in the serv­er farm are bal­anced (if this serv­er par­tic­i­pates in a load-bal­anced serv­er farm).

Each of the dashboard’s four pan­els can be max­i­mized to either pro­vide more detail (as with arche­type libraries or with zone health) or pro­vide sys­tem admin­is­tra­tors the abil­i­ty to over­ride ZIServer’s tun­able para­me­ters. The detailed view of the Zone Health pan­el dis­plays agent health for each agent that has pend­ing mes­sages.

The ZIServer Neighborhood — Zones

We have redesigned ZIServer’s inter­face to sup­port many thou­sands of SIF zones by mak­ing the list of zones a paged, scrol­lable list. When a zone is select­ed from the top list, the low­er half of the screen updates to show:

  • any mes­sages wait­ing to be sent to any of the agents in that zone
  • all detailed infor­ma­tion for the zone – in this tab, admin­is­tra­tors are allowed to change select­ed infor­ma­tion for the zone

The ZIServer Neighborhood — Agents

When the ‘+’ icon is pressed at the begin­ning of one of the zone rows, that row expands to show infor­ma­tion for all of the agents in that zone. The low­er half of the screen now shows detailed infor­ma­tion for the select­ed agent in the agent list.

For each agent, the low­er screen dis­play shows:

  • mes­sages wait­ing to be sent to the agent
  • detailed infor­ma­tion about the agent (some was entered when the agent was cre­at­ed, oth­er was received when the agent reg­is­tered and still oth­er infor­ma­tion may be entered by and admin­is­tra­tor)
  • object per­mis­sions (ACL list)
  • ele­ment-lev­el fil­ters
  • a list of the objects that this agent is pro­vid­ing
  • a list of the objects to which this agent is sub­scrib­ing

The ZIServer Neighborhood — Viewing Waiting Messages

While a mes­sage is wait­ing, it can be viewed by press­ing the hour­glass icon at the end of its detail row. This will bring up a win­dow that looks like the image on the left, dis­play­ing the mes­sage.

Secu­ri­ty / Pri­va­cy Fea­tures

Besides pass­ing mes­sages from one appli­ca­tion to anoth­er, man­ag­ing secu­ri­ty is the oth­er main func­tion of the ZIS­erv­er prod­uct. The fol­low­ing table illus­trates some of these ZIS­erv­er fea­tures:

ZIServer Accounts

ZIS­erv­er pro­vides web-based admin­is­tra­tion and man­age­ment with sep­a­rate roles for Glob­al Admin­is­tra­tors (all capa­bil­i­ties in all zones), Zone Admin­is­tra­tors (most capa­bil­i­ties for spec­i­fied zones) and Agent View­ers (lim­it­ed capa­bil­i­ties for spec­i­fied con­nec­tions).

This is a screen cap­ture from a Glob­al Administrator’s account which allows admin­is­tra­tion of all oth­er accounts.

ZIServer Zone Level Administrators

This is a view from a Glob­al Administrator’s account where a Zone Administrator’s account is being set up. In this exam­ple, the account ‘bwilde’ is giv­en access to two zones.

ZIServer Agent (connector) Level Administrators

In this exam­ple, the account ‘opayne’ is giv­en access to view some lim­it­ed infor­ma­tion from agents (con­nec­tors) in two zones. In the cur­rent­ly select­ed zone, access is only giv­en to infor­ma­tion about the ‘Sub­scriberB’ agent (con­nec­tor).

Object-Level Permissions

ZIS­erv­er main­tains object lev­el priv­i­leges by appli­ca­tion con­nec­tor to send events (Add, Change or Delete), sub­scribe to events, make requests or respond to requests. Agents (con­nec­tors) need to be pre-autho­rized by the admin­is­tra­tor before they can pub­lish or receive data to or from a zone. The last col­umn in the per­mis­sions table con­tains a but­ton. If the but­ton is green, there are ele­ment-lev­el fil­ters defined for this object (but none have been set). If the but­ton is yel­low, some fil­ters have been set.

Element-Level Filtering

ZIS­erv­er sup­ports ele­ment-lev­el fil­ter­ing by agent con­nec­tion. This allows admin­is­tra­tors to define pri­va­cy fil­ters for object types by appli­ca­tion, caus­ing data to be removed from mes­sages before deliv­er­ing them to the appli­ca­tion (based on a need-to-know basis). For exam­ple, in the SIF edu­ca­tion stan­dard, there is a “Med­ical Alert” field in the Stu­dent Demo­graph­ics object. Since this is not need­ed by (and, for pri­va­cy rea­sons, should not be sent to a Library appli­ca­tion, that one field can be removed before pass­ing the mes­sage to the Library appli­ca­tion. Dur­ing the pub­li­ca­tion of the same event, the entire mes­sage would be for­ward­ed to the Nurse’s office appli­ca­tion. All ver­sions of deliv­ered mes­sages are audit­ed sep­a­rate­ly.

In this screen, an admin­is­tra­tor may choose to remove/replace cer­tain ele­ments (fields) from mes­sages before they are sent to a receiv­ing appli­ca­tion. The admin­is­tra­tor is also able to con­trol glob­al­ly whether ele­ments are replaced (with a string such as “removed for pri­va­cy rea­sons”) or sim­ply removed.

HTTP/HTTPS Authentication

ZIS­erv­er sup­ports sev­er­al authen­ti­ca­tion (includ­ing cer­tifi­cate pin­ning) and encryp­tion mod­els (includ­ing TLS 1.2 and 1.3) for bank-lev­el secu­ri­ty. The set-up is sim­ple: install a cer­tifi­cate on the serv­er where ZIS­erv­er is being installed, obtain a copy of the remote server’s cer­tifi­cate, and copy it to a secure place on the local serv­er. Last­ly, tell ZIS­erv­er where that local copy is, and it will con­fig­ure the rest and han­dle all the dif­fi­cult parts.

Flex­i­bil­i­ty — Oth­er Appli­ca­tions

Although orig­i­nal­ly cre­at­ed for the edu­ca­tion mar­ket (as were all oth­er prod­ucts in the Visu­al Soft­ware suite), ZIS­erv­er was designed to sup­port any class of appli­ca­tion from any indus­try, from a small, local­ly devel­oped data­base sys­tem to a mul­ti-serv­er, line-of-busi­ness sys­tem. How­ev­er, some envi­ron­ments will be eas­i­er to con­nect than oth­ers because they already have indus­try-wide stan­dards avail­able. A par­tial list of these include:

  • Agri­cul­ture: AgXML (grain- and oilseed-relat­ed busi­ness process­es)
  • Auto­mo­tive
    • STAR — STan­dards in Auto­mo­tive Retail
    • OTX — Open Test sequence eXchange
  • Busi­ness
    • B2MML (Busi­ness to Man­u­fac­tur­ing)
    • CIDX (Chem­i­cal Indus­try Data Exchange)
    • FpML (set of Finan­cial Prod­ucts stan­dards)
    • HR-XML (Human Resources relat­ed stan­dards)
    • Mail.XML (Mail­ing, Address­es and Deliv­er­ies)
    • OASIS UBL (Busi­ness Doc­u­ments, Process­es)
    • RETS (Real Estate Trans­ac­tions)
    • XBRL (Busi­ness Report­ing)
  • Edu­ca­tion
    • SIF (Sys­tems Inter­op­er­abil­i­ty Frame­work)
    • IMS glob­al learn­ing con­sor­tium (a set of stan­dards)
  • Health Care: HL7 — Health Lev­el 7
  • Gov­ern­ment — NIEM (set of stan­dards)
  • News
    • EventsML (News Exchange)
    • SportsML (Sports Data)
  • Pub­lish­ing
    • AdsML (Adver­tis­ing)
    • pap­iNet (Paper and For­est Sup­ply Chain)
    • Prism (Pub­lish­ing Con­tent)
    • RIXML (Glob­al Invest­ment Research)
  • Sci­en­tif­ic: DWML (Dig­i­tal Weath­er)
  • Secu­ri­ty: OVAL (Open Vul­ner­a­bil­i­ty and Assess­ment Lan­guage)

Host­ing Capa­bil­i­ties

ZIS­erv­er was designed from the ground up to sup­port a host­ed imple­men­ta­tion mod­el. In a sin­gle imple­men­ta­tion, it sup­ports thou­sands of zones (groups of relat­ed appli­ca­tions), each of which is capa­ble of con­nect­ing dozens to hun­dreds of appli­ca­tions.

ZIS­erv­er also sup­ports glob­al admin­is­tra­tion as well as dis­trib­uted admin­is­tra­tion. In a host­ed envi­ron­ment, the glob­al admin­is­tra­tor would work for the host­ing provider where a dis­trib­uted admin­is­tra­tor (or zone admin­is­tra­tor) role would be giv­en to a cus­tomer account. For more infor­ma­tion on this, see “Secu­ri­ty / Pri­va­cy Fea­tures” above.

Per­for­mance

A Little History

When we cre­at­ed our first ver­sion of ZIS­erv­er, we built it “on top of” a pop­u­lar Enter­prise Appli­ca­tion Inte­gra­tion (EAI) plat­form. It did the same basic things that our cur­rent ZIS­erv­er prod­uct does (passed mes­sages and man­aged per­mis­sions), but it required our cus­tomers to buy a copy of the EAI plat­form when they pur­chased our ZIS­erv­er prod­uct.

In 2007, we were work­ing with an exist­ing XML spec­i­fi­ca­tion that was chang­ing and not main­tain­ing back­wards com­pat­i­bil­i­ty. Because this also involved changes to the trans­port mech­a­nism (how mes­sages are passed between appli­ca­tions), it was forc­ing us into a ground-up rewrite. At the same time, we heard from the mak­er of the EAI plat­form that their next release was not going to be back­wards-com­pat­i­ble. In addi­tion, it was still over a year away from being released. This left us with reduced options.

Assessing Our Strengths and Market Needs

At that point, we saw that the cur­rent prod­uct worked well, but it lacked the per­for­mance need­ed by very large . In addi­tion, because it required cus­tomers to also pur­chase an EAI plat­form, it exclud­ed small­er poten­tial cus­tomers who couldn’t admin­is­ter or afford the EAI plat­form. Since we had an exten­sive back­ground in oper­at­ing sys­tem-lev­el devel­op­ment already, we decid­ed to cre­ate a new gen­er­a­tion ZIS­erv­er from the ground up, based on the design prin­ci­ples we were most famil­iar with: . As a result of a sig­nif­i­cant devel­op­ment effort, our base mod­el was ready. After a side-by-side com­par­i­son, we found that it was:

  • sig­nif­i­cant­ly faster than the old­er ver­sion based on the EAI plat­form. It was rough­ly 8–15 times faster, depend­ing on the mix of traf­fic.
  • more scal­able. The new ver­sion could han­dle load-bal­anced input as well as load-bal­anced out­put – an advan­tage it still offers even today.
  • eas­i­er to admin­is­ter. We were able to cre­ate an installer that allowed for a sim­ple, “click-through” process and an easy-to-use GUI admin­is­tra­tive inter­face.
  • much more afford­able. The new ver­sion didn’t require the pur­chase of the EAI plat­form.

Since Then

We have spent the years since then improv­ing ZIServer’s speed, scal­a­bil­i­ty and over­all usabil­i­ty. We’ve improved the prod­uct in these ways with­out increas­ing its admin­is­tra­tive com­plex­i­ty or sys­tem-lev­el basic require­ments. This allows us to still sup­port imple­men­ta­tions of all sizes with­out requir­ing ded­i­cat­ed admin­is­tra­tive sup­port, even in the largest instal­la­tions.

Scal­a­bil­i­ty / High Avail­abil­i­ty

The new ZIS­erv­er has many fea­tures to sup­port large and/or host­ed imple­men­ta­tions:

  • It sup­ports a one-to-many mod­el. This is ide­al in sit­u­a­tions where infor­ma­tion pub­lished by one source needs to be dis­trib­uted to sev­er­al recip­i­ents. With this mod­el
    1. the pub­lish­er doesn’t need to keep track of who needs to receive the mes­sage. (The list of sub­scribers can change with­out requir­ing that the pub­lish­er be noti­fied.)
    2. the pub­lish­er only sends a sin­gle mes­sage (less net­work traf­fic).
    3. the speed at which the pub­lish­er sends mes­sages is not depen­dent on the speed at which receivers are able to receive mes­sages.
    4. mes­sages can be screened for pri­va­cy at ZIS­erv­er if need­ed.
  • It retains mes­sages across agent and sys­tem fail­ures. If any of the end­points goes offline, ZIS­erv­er saves its mes­sages and sends them when the appli­ca­tion returns to an online state – even if it takes days to do so.
  • It pro­tects the envi­ron­ment against XML-based denial-of-ser­vice attacks (the only bro­ker of its kind to offer this pro­tec­tion).
  • It guar­an­tees that mes­sages are deliv­ered in .
  • It may be deployed as a high-avail­abil­i­ty serv­er farm on as many servers as need­ed in sin­gle or mul­ti­ple loca­tion (dis­as­ter recov­ery) con­fig­u­ra­tions. ZIS­erv­er is the only mes­sage bro­ker of its kind to offer load-bal­anced deliv­ery of mes­sages (oth­ers pro­vide dis­trib­uted mes­sage receiv­ing capa­bil­i­ties). Pro­vid­ing load-bal­anc­ing in both direc­tions gives ZIS­erv­er a unique advan­tage in the areas of:
    • Over­all through­put
    • Serv­er failover and recov­ery – events in both direc­tions are han­dled auto­mat­i­cal­ly with­in mil­lisec­onds
  • It has been cer­ti­fied by the A4L orga­ni­za­tion.
  • It sup­ports incre­men­tal adop­tion; dif­fer­ent mod­els of ZIS­erv­er are avail­able from Com­pact Edi­tion (sin­gle small serv­er) to large Enter­prise Edi­tion instal­la­tions. Migrat­ing from a small­er edi­tion to a larg­er edi­tion can be done with­out the loss of any infor­ma­tion and can often be done with­out any down­time.

Typ­i­cal­ly, Enter­prise Appli­ca­tion Inte­gra­tion (EAI) soft­ware is referred to by terms such as "Point-to-Point" (P2P), "Enter­prise Ser­vice Bus" (ESB) or "Hub and Spoke" (HAS). ZIS­erv­er falls some­where in the cat­e­go­ry of a "Fed­er­at­ed Hub-and-Spoke" mod­el, pro­vid­ing all of its advan­tages with­out the dis­ad­van­tages for which oth­er EAI mod­els are crit­i­cized. For more infor­ma­tion, see: EAI Mod­els

Audit­ing

ZIS­erv­er audits each mes­sage that is passed through it. The appli­ca­tion main­tains two “work­ing data­bas­es” one for active mes­sages and anoth­er for audits. They are sep­a­rat­ed so that the audits’ data can be stored on dif­fer­ent stor­age from the active mes­sages and also for per­for­mance rea­sons. It also stores dif­fer­ent lev­els of audits The Admin­is­tra­tion util­i­ty has a con­ve­nient capa­bil­i­ty that allows admin­is­tra­tors and des­ig­nat­ed users to be able to search through recent­ly deliv­ered mes­sages and dis­play their con­tents.

The Audits Interface

Some of the fea­tures of this inter­face are:

  • Columns can be sort­ed by click­ing on the col­umn head­er
  • Columns with a fun­nel icon in the col­umn can be fil­tered
  • Data can be grouped by any col­umn by drag­ging the col­umn head­er to the gray bar above the col­umn head­er bar
  • Mes­sage con­tents can be viewed by click­ing on the mes­sage link at the end of any line
  • Mes­sage con­tents can be searched by using the "Search Mes­sage Con­tents" fea­ture at the top of the page

This inter­face has been designed to work effi­cient­ly with hun­dreds of thou­sands to mil­lions of audit records.

In addi­tion, it is also user-account sen­si­tive. If a zone admin­is­tra­tor views this page, the audit records dis­played will only be from agents in the zones that he or she is allowed to access. This works sim­i­lar­ly with agent view­ers.

The Audits Interface — Docking Messages

Nor­mal­ly when an audit mes­sage is viewed, it is dis­played in a pop-up win­dow. If the user drags that win­dow to the side of the screen, it can be docked, and the audit list will be resized accord­ing­ly.

The Audits Interface — Viewing Multiple Messages

If mul­ti­ple mes­sages are viewed simul­ta­ne­ous­ly, the mes­sage win­dow can be dragged (see below) to join an exist­ing mes­sage and form a tab-card col­lec­tion of such win­dows.

Veracity

Veracity — Data Integrity Manager

XML data exchange spec­i­fi­ca­tions (such as SIF for the edu­ca­tion mar­ket) enable appli­ca­tions to exchange data, so that once it is made avail­able in one place, it can be put to good use every­where else as well. In the process, valu­able infor­ma­tion from all sorts of appli­ca­tions cross­es the inter­op­er­abil­i­ty "zone." We rec­og­nize this flow as an asset in and of itself, and we tap into it with Verac­i­ty.

The Repository and Data Quality Management

Verac­i­ty is our unique repos­i­to­ry of exchanged, stan­dard­ized objects. It lever­ages the infrastructure's event and request/response facil­i­ties to keep an up-to-date snap­shot of the cur­rent sta­tus of all objects being exchanged. Once in Verac­i­ty, it doesn't mat­ter whether the data came from a trans­porta­tion sys­tem or a food ser­vices sys­tem, it is avail­able from one place under one data schema.

Can you trust your data? Is it accu­rate and depend­able?
When it comes to mak­ing deci­sions based on your district’s data, one of the biggest chal­lenges to over­come is that of data integri­ty. Can you trust your data? Is it accu­rate and depend­able?

One of the fun­da­men­tal goals in data integri­ty man­age­ment is to move the cor­rec­tion of data errors back to the source. In an edu­ca­tion envi­ron­ment, for exam­ple, when cen­sus data is being pre­pared at a school dis­trict, the IT staff col­lects the data from the var­i­ous sys­tems in the school, match­es up the records, cleans them, for­mats the result, and then sub­mits it. This cycle is repeat­ed sev­er­al times dur­ing the school year. Many times the same error is cor­rect­ed over and over because it gets fixed in the CSV file instead of the source sys­tem.

This is why we have cre­at­ed Verac­i­ty. The Verac­i­ty approach is the fol­low­ing:

  • Estab­lish a com­mon repos­i­to­ry that always reflects the cur­rent state of the data in the source appli­ca­tions (Verac­i­ty).
  • Mon­i­tor the qual­i­ty of the data by apply­ing a set of rules and look­ing for prob­lem areas.
  • Noti­fy the own­er of the data in ques­tion so that it can be cor­rect­ed in the source appli­ca­tion.
  • Use the data from the repos­i­to­ry as the source for state reports, cross-appli­ca­tion reports or as a feed into a data ware­hous­ing sys­tem.

By mov­ing the cor­rec­tion of the prob­lem back to the source of the error:

  • All appli­ca­tions in the zone ben­e­fit from the bet­ter-qual­i­ty data.
  • The data is changed only once and in one place.
  • Your data becomes more reli­able, giv­ing you more con­fi­dence in deci­sions you make that results from the data's analy­sis.

See if you can rely on your data. The first thing to know is how close the qual­i­ty of your data is to the stan­dards defined by your orga­ni­za­tion.

Veracity’s rule set artic­u­lates your district’s data qual­i­ty rules, applies them against data col­lect­ed from the con­nect­ed sys­tems and shows you where your district’s data falls short.

These rules can be checked on a sched­uled basis or in real time as data is pub­lished.

Viewing Errors in Data (Education Example)

See How You Are Progressing

This chart shows what types of errors you have and how they are dis­trib­uted. If you click on the chart and hov­er over one of the slices, it tells you how many errors of that type there are. Click­ing on the image will cause a full size image to open in a new win­dow.

Verac­i­ty requires that errors be cor­rect­ed at their source, and it does not allow changes to be made in the repos­i­to­ry.

Instead, it pro­vides a set of tools that help peo­ple track errors and cor­rect them at the source, so that all oth­er sys­tems con­nect­ed through the SIF inter­face can also ben­e­fit when they are cor­rect­ed.

The graph to the right gives users a sense of how the district’s data is improv­ing over time. Click­ing on the image will cause a full size image to open in a new win­dow.

The dif­fer­ent col­ors rep­re­sent errors, warn­ings and oth­er items of inter­est. If you click on this graph, it scrolls from side to side and, like the oth­er graph, if you click and hov­er over a bar, it shows you the spe­cif­ic num­ber of errors in a spe­cif­ic cat­e­go­ry.

In this exam­ple, the data was checked sev­er­al times. As the data was checked, errors were being cor­rect­ed at the source until the last sam­ple, where some new rules were intro­duced. These new rules caught addi­tion­al errors in the source data.

Seeing Error Details

See­ing the details is also impor­tant. This screen allows you to view and drill down into the error details. This screen shows a sum­ma­ry of each rule that has been vio­lat­ed by data in your orga­ni­za­tion as well as how many records vio­late that rule. Click­ing on the “View Records” link allows you to see stu­dent-lev­el detail for a spe­cif­ic cat­e­go­ry.

Seeing Student Details

Click­ing on the “View Detail” link allows you to drill down to the stu­dent detail lev­el.

Viewing Student Detail Record

This student’s record vio­lat­ed rules: the birth date/school rea­son­able­ness and the school dis­trict age lim­it test rule. At the bot­tom of the screen, both rules are sum­ma­rized. The spe­cif­ic word­ing for each of these rules can be mod­i­fied by the Verac­i­ty admin­is­tra­tor through this web inter­face to word them accord­ing to local pol­i­cy def­i­n­i­tions. NOTE: Stu­dent infor­ma­tion used in these screen cap­tures are for fic­tion­al stu­dent records ran­dom­ly cre­at­ed from lists of pop­u­lar last and first names. Any resem­blance to real per­sons, liv­ing or dead, is pure­ly coin­ci­den­tal.

At the bot­tom of this screen (not shown) would be a sum­ma­ry of oth­er rules that have also been vio­lat­ed by this record (there could be sev­er­al prob­lems with this record).

Defining Rules

Verac­i­ty helps you con­tin­u­ous­ly mon­i­tor the qual­i­ty of your organization's data by giv­ing you an abil­i­ty to sim­ply define data integri­ty rules that will be run against the con­sol­i­dat­ed data in Verac­i­ty and point out to your staff where data needs to be cor­rect­ed. It pro­vides a sim­ple con­fig­u­ra­tion form to define rules such as "make sure every ele­men­tary school child who lives more than a half mile from school is on a bus route" or "make sure that every child has been assigned to at least one but not more than two schools".

Sets of rules can be estab­lished for dif­fer­ent pur­pos­es. For exam­ple, you may want to run gen­er­al stu­dent infor­ma­tion checks on a dai­ly basis while oth­er, more detailed checks may only be appro­pri­ate once the "begin­ning of the school year crunch" has passed.

Rules are defined through a web inter­face (assum­ing that the user has admin­is­tra­tive rights) using a process that typ­i­cal­ly takes only a few min­utes per rule.

Data Qual­i­ty Gate­way

Overview

When an application’s input process is auto­mat­ed, and it begins to receive its input from a new source (not man­u­al­ly through its own , the sub­scrib­ing appli­ca­tion may start to exhib­it “new behav­iors.”

We found this out from our work with the spe­cial edu­ca­tion com­mu­ni­ty in the US. They began to receive data from an asso­ci­at­ed stu­dent man­age­ment sys­tem, but typ­i­cal­ly, the data they already had was bet­ter qual­i­ty than the new data they were receiv­ing from the . They referred to the new auto­mat­ed data as “data pol­lu­tion.” Sit­u­a­tions like this occur wher­ev­er input is auto­mat­ed, but its effects can be mit­i­gat­ed. The way we addressed this chal­lenge was through some­thing we call a “Data Qual­i­ty Gate­way.”

Clean Zones

Verac­i­ty sets up two data­bas­es to store data col­lect­ed from the schools, referred to as the “raw zone” and the “clean zone”. The raw zone stores data in the form received from the schools. The clean zone con­tains only data that has been test­ed and judged to be of good enough qual­i­ty to be shared with oth­er appli­ca­tions.

This is how it works: as the data arrives, Verac­i­ty checks it for valid­i­ty against data qual­i­ty poli­cies defined by the min­istry (imple­ment­ed as busi­ness rules in Verac­i­ty). Data that pass­es all of the qual­i­ty checks is imme­di­ate­ly copied to the “clean zone” and becomes avail­able for con­nect­ed appli­ca­tions. Data that fails any of the tests is held in the “raw zone,” and the own­er of the data is noti­fied. A user inter­face is pro­vid­ed for that user to see where the errors are so that the errors can be cor­rect­ed at their source. Once an error is cor­rect­ed, the change comes through the SIF inter­face and the record is released to the clean zone, pro­vid­ing con­nect­ed sys­tems with up-to-date, usable infor­ma­tion.

In the fol­low­ing dia­gram, the SMS appli­ca­tions rep­re­sent the sources of infor­ma­tion (Stu­dent Man­age­ment Sys­tems), and the Sub­scrib­ing Appli­ca­tion rep­re­sents the place where an extra­or­di­nar­i­ly high lev­el of qual­i­ty is required (a much high­er lev­el than what is deliv­ered by the SMS sys­tems).

When a rule is set up at con­fig­u­ra­tion time, there are sev­er­al options avail­able with respect to the gate­way:

  • If the incom­ing mes­sage does not meet the require­ments, noti­fy the source of the data and do not pass the data to the sub­scribers.
  • If the incom­ing mes­sage does not meet the require­ments, noti­fy the source of the data and pass the data to the sub­scribers (warn­ing only).
  • If a test­ed field caus­es the data to not meet require­ments, noti­fy the source of the data and do not pass the data to the sub­scribers.
  • If a test­ed field caus­es the data to not meet require­ments, noti­fy the source of the data and pass the record to the sub­scribers WITHOUT the test­ed field’s val­ue.

The tests that are set up can involve any data in the incom­ing data record. Addi­tion­al­ly, they can also test val­ues in pre­vi­ous­ly received data in this table or in oth­er tables.

Verac­i­ty User Inter­face Appear­ance

Look and Feel

We have found that with many cus­tomers, the func­tion­al­i­ty that Verac­i­ty pro­vides belongs on the desk­top of those who reg­u­lar­ly enter data into line of busi­ness appli­ca­tions. Many of these users are already like­ly to be logged into an orga­ni­za­tion-wide por­tal that pro­vides oth­er ser­vices need­ed dur­ing the day.

For this rea­son, we gave Verac­i­ty the abil­i­ty to adopt the look and feel of almost any oth­er web­site with a few sim­ple steps (per­formed by an admin­is­tra­tor) in a mat­ter of a few hours. The Verac­i­ty user inter­face has about 30 dif­fer­ent parts (page head­ing, foot­er, top of a table, table cell, etc.) – the things you would find on most por­tal sites. As it is being con­fig­ured, an admin­is­tra­tor views the source of a por­tal page, copies the style from it into Verac­i­ty and the user inter­face is trans­formed with­out cod­ing. This allows the Verac­i­ty inter­face to then be embed­ded as part of the organization’s por­tal and look like it was always meant to be there.

Verac­i­ty Con­sol­i­dat­ed Data Access — Report­ing

Using the Combined Data

At Visu­al Soft­ware, we under­stand that a school’s busi­ness is not the num­bers and strings passed around from appli­ca­tion to appli­ca­tion, but what those data ele­ments rep­re­sent. You have data that describes how a child is doing, from dis­ci­pline to grades to atten­dance. The prob­lem is that there is just too much data for any human to keep track of and use effec­tive­ly at the stu­dent lev­el.

You may already have sys­tems that give detailed reports to prin­ci­pals, guid­ance coun­selors and oth­er staff mem­bers. But what hap­pens when you take one line from three dif­fer­ent reports, only to find out that the com­bined lines sig­nal a prob­lem, while none of lines raise any red flags on their own? For exam­ple, a par­tic­u­lar student’s GPA may be drop­ping at the same time as their atten­dance is wors­en­ing and their dis­ci­pline inci­dents are increas­ing. Any one of these fac­tors viewed inde­pen­dent­ly might not get much atten­tion, but put togeth­er, they might sig­nal a child “drop­ping off the edge.” If this infor­ma­tion was main­tained by dif­fer­ent sys­tems or if the infor­ma­tion was not avail­able in a con­sol­i­dat­ed report, that impor­tant indi­ca­tor might be lost.

Verac­i­ty col­lects and com­bines infor­ma­tion from whichev­er appli­ca­tions are pub­lish­ing in a zone. Records from these dif­fer­ent sys­tems for com­mon stu­dents, teach­ers, par­ents, and class­es (groups) are auto­mat­i­cal­ly matched, allow­ing users to access its under­ly­ing data­base to cre­ate con­sol­i­dat­ed reports using tools such as SQL Report­ing and Analy­sis Ser­vices.

Verac­i­ty Form Design­er

In a sys­tem like this, espe­cial­ly when we cre­ate new indus­try spec­i­fi­ca­tions, the need for many forms aris­es – forms to dis­play errors, search (and edit) data, and show detailed records for each type of object. This is what con­sumes an over­whelm­ing amount of time for most com­pa­nies try­ing to imi­tate what we do. We knew that this devel­op­ment would quick­ly make imple­men­ta­tions like these unaf­ford­able for those who need them most. So, we built a frame­work into Verac­i­ty to quick­ly add sets of forms with rich func­tion­al­i­ty for each new object we added to a new inter­op­er­abil­i­ty spec­i­fi­ca­tion.

The Form Designer

For each object that will be qual­i­ty-checked in an inter­op­er­abil­i­ty spec­i­fi­ca­tion (such as SIF, HL7, etc.), a set of forms is need­ed by Verac­i­ty to dis­play poten­tial errors and allow users to browse through the con­sol­i­dat­ed data (if so desired). These include forms to:

  • Dis­play errors
  • Enter search cri­te­ria (con­fig­ured by user as not all fields are search­able)
  • Show a list of search match­es
  • Show search results with any errors
  • Edit records (option­al)
  • Delete records (option­al)
  • Man­age attach­ments (option­al)

The option­al forms above are for oth­er appli­ca­tions (not the data qual­i­ty check­ing described above).

Once the forms have been cre­at­ed here, they are ready to be used in data qual­i­ty rules. They can now be added to the nav­i­ga­tion, allow­ing users to browse through objects of this type.

The Object Search Screen

For objects where Verac­i­ty cus­tomers want to pro­vide users search (and option­al­ly update) access to the com­bined data, a search facil­i­ty will auto­mat­i­cal­ly be added to the inter­face. This hap­pens only after a form for the object has been defined, and the object has been added into the nav­i­ga­tion struc­ture.

Users can be restrict­ed by scope (for exam­ple, US edu­ca­tion users can be restrict­ed by all statelev­el data, school dis­trict lev­el data or school lev­el data only) or can be giv­en access to all data. Search­es can be spec­i­fied by using nat­ur­al lan­guage queries. For exam­ple, if the user is search­ing a date field, he or she could search using: “this year”, “ytd”, “1÷15÷2015−4÷2÷2016”, “4÷2017” or “before May 2013”. We tried to antic­i­pate what our users might type when search­ing and imple­ment­ed it, includ­ing what hack­ers might type and pre­vent­ed it from doing any­thing.

In this exam­ple, the user is search­ing for “Stu­dents” with the let­ters “jo” any­where in their Last­Name. If mul­ti­ple strings are entered, it will search as if an “OR” were between them. (Log­i­cal oper­a­tors such as AND, OR and NOT can be used in search­es.)

Search Results

This screen shows the results from the pre­vi­ous search. The fields shown here were spec­i­fied in the Form Designer’s “Dis­play in Search Results” field. For a giv­en field, if the val­ue was set, the field will show in this form.

At the begin­ning of each row is a link that allows the user to get to the details for this record.

Record Detail

This screen shows the detailed infor­ma­tion for the select­ed stu­dent. NOTE: Stu­dent infor­ma­tion used in these screen cap­tures are for fic­tion­al stu­dent records ran­dom­ly cre­at­ed from lists of pop­u­lar last and first names. Any resem­blance to real per­sons, liv­ing or dead, is pure­ly coin­ci­den­tal.

At the bot­tom of this screen (not shown) would be a sum­ma­ry of rules that have been vio­lat­ed by this record (there could be sev­er­al prob­lems with this record).

Mimic

Mimic — Interoperability Adapter for Legacy Applications

Mim­ic is an inter­face designed for cer­tain types of appli­ca­tions that were nev­er intend­ed to be mem­bers of a con­nect­ed zone. These appli­ca­tions con­tain need­ed infor­ma­tion and can cre­ate com­ma delim­it­ed extract (often referred to as Com­ma Sep­a­rat­ed Val­ues or CSV) files and have the abil­i­ty to export them to a fixed loca­tion on a reg­u­lar basis. Exam­ples of appli­ca­tions like this might be:

  • Main­frame infor­ma­tion sys­tems
  • Excel® spread­sheets
  • Small data­base files with line of busi­ness infor­ma­tion
  • Local­ly devel­oped appli­ca­tions
  • Appli­ca­tions where the sup­pli­er does not have an inter­est in shar­ing infor­ma­tion – in which case, a con­nec­tor like ZIA­gent can be used to con­nect the appli­ca­tion in real time and export its need­ed infor­ma­tion to a CSV file

In design­ing Mim­ic, we knew that there was a need for some­thing that would:

  • Sup­port those "for­got­ten" appli­ca­tions
  • Be very sim­ple to set up
  • Not require any assis­tance to run
  • Not be expen­sive to install and main­tain

What Does Mimic Do?

Mim­ic looks at the extract file's con­tents and com­pares it against the file it looked at the last time it ran (the agent runs on a reg­u­lar­ly sched­uled basis).

If there are new records, it pub­lish­es "Add" events to the Zone.I If records have changed, it pub­lish­es "Change" events. If records are miss­ing, it pub­lish­es "Delete" events. It also archives back­up copies of the CSV files it has processed and audits any events it has gen­er­at­ed.

Mim­ic responds to requests from oth­er appli­ca­tions with appro­pri­ate response mes­sages as would a ZIA­gent con­nec­tor from the appli­ca­tion itself.

Mim­ic needs a sup­port­ing data­base (to keep track of what your file looked like last time and to keep track of its con­fig­u­ra­tion infor­ma­tion), and we chose a spe­cif­ic data­base fam­i­ly: Microsoft® SQL Serv­er® (unlike our oth­er prod­ucts which will work with many dif­fer­ent data­bas­es). We also chose a spe­cif­ic oper­at­ing sys­tem plat­form: Microsoft Win­dows Serv­er or Win­dows 10. In lim­it­ing these choic­es, we were able to make the con­fig­u­ra­tion and deploy­ment process sim­ple and straight­for­ward to fur­ther reduce the cost of sup­port­ing the plat­form.

How Does Mimic Differ from ZIAgent?

ZIA­gent is a full-fea­tured, con­fig­urable con­nec­tor that works with any appli­ca­tion, provider or sub­scriber. It han­dles incom­ing requests, events and any­thing else defined in the XML spec­i­fi­ca­tion. It works with appli­ca­tions that use any type of data­base and offers a host of appli­ca­tion inter­faces. Mim­ic only pro­vides objects and does not sup­port inbound traf­fic (sub­scribers). For more infor­ma­tion on ZIA­gent, select the ZIA­gent tab above.

How Does it Work?

Mimic's configuration/management is done through a wiz­ard process that guides the user through a sim­ple set­up match­ing and job con­fig­u­ra­tion process.

When the appli­ca­tion first opens, Mim­ic dis­plays a list of objects con­fig­ured for this instal­la­tion. In this exam­ple, although there are over 120 objects that are avail­able for con­fig­ur­ing, this instal­la­tion has only con­fig­ured 3 so far, and it is about to con­fig­ure a fourth. To see the com­plete list, press “Show All.”
In the first step, the user brows­es to a sam­ple CSV file con­tain­ing data for the object being con­fig­ured. This sam­ple should be var­ied enough to cov­er most cas­es that will be encoun­tered. Mim­ic will read this file and show the user the first few lines from the file. It will also learn what­ev­er it can about the data from read­ing the file.
The user is then asked which of the fields will be used from this input file.
The user then has to choose one or more fields that can be used to cre­ate a unique iden­ti­fi­er. Up to 9 fields may be select­ed.
Then, fields need to be mapped – the appli­ca­tion CSV file calls it “X” and the stan­dard refers to it as “Y.” For exam­ple, in the CSV file, a field may be named “Last­Name”, while the XML stan­dard refers to is as “Fam­i­ly­Name.”

If a giv­en field is linked to a field in anoth­er object, a “LOOKUP” but­ton is dis­played and the user is asked to map the fields in this file that cor­re­spond to the match­ing fields in the oth­er file. For exam­ple, the field in this record refers to the “School Dis­trict (LEA) Iden­ti­fi­er” – this refers to the unique iden­ti­fi­er of the “School Dis­trict (LEA)” object.

When all of the fields are mapped, the process is almost com­plete for this object.
The last step in the process is sched­ul­ing how often this object’s files are to be processed. We pro­vide sep­a­rate sched­ules for every object because, for exam­ple, school dis­trict infor­ma­tion doesn’t get updat­ed very fre­quent­ly, where­as stu­dent class enroll­ment infor­ma­tion or assess­ment infor­ma­tion would be updat­ed much more fre­quent­ly.
This is an exam­ple of an audits screen. Com­plete audits are main­tained for every mes­sage sent. This screen lets an admin­is­tra­tor look through top-lev­el infor­ma­tion for all mes­sages, then drill down if need­ed.

Two Editions

Visu­al Soft­ware has cre­at­ed two ver­sions of Mim­ic:

  • Mim­ic Stan­dard: This is aimed at a small­er, sin­gle loca­tion pub­lish­er. It pub­lish­es to a sin­gle zone using a sin­gle pre­de­fined XML spec­i­fi­ca­tion.
  • Mim­ic Enter­prise: This is sim­i­lar to Mim­ic Stan­dard, but it is aimed at orga­ni­za­tions with many loca­tions. It sup­ports mul­ti­ple, inde­pen­dent zones and it is imple­ment­ed as a local­ly host­ed ser­vice.

Dexterity

Dexterity — Remote Monitoring and Predictive Maintenance

The Problem — Simply Stated

Com­put­ers are very good at keep­ing lists of things that need to be done as well as when they need to be done. Com­put­ers have numer­ous sen­sors that can detect if the hard­ware is run­ning nor­mal­ly or start­ing to fail. Com­put­ers can also be taught to gath­er infor­ma­tion about the oper­at­ing sys­tem (Win­dows), data­base sys­tems, and impor­tant appli­ca­tions (such as your line of busi­ness sys­tems) to make sure they are oper­at­ing at peak effi­cien­cy.

For years, peo­ple have used these char­ac­ter­is­tics to build soft­ware to mon­i­tor envi­ron­ments, local­ly and remote­ly. When a prob­lem is detect­ed, the remote man­age­ment software’s infor­ma­tion is used to assign peo­ple to fix the issue.

That's where we were sev­er­al years ago when we were asked to pro­vide man­aged ser­vices for some of our larg­er cus­tomers. We used remote man­age­ment soft­ware in their large envi­ron­ment, and it alert­ed us when there was an issue in one of the envi­ron­ments. One of the biggest issues we faced was that the root cause of the prob­lem that need­ed fix­ing came so fast and strong (and most times unex­pect­ed­ly) that by the time we could get to fix­ing it, the prob­lem had esca­lat­ed past the point where a sim­ple solu­tion was pos­si­ble.

Some Examples When This Could / Does Happen

These are some exam­ples where Dex­ter­i­ty would be or has been very effec­tive:

Snow Days / Office Closed

For exam­ple, an edu­ca­tion cus­tomer in a snowy region of the coun­try col­lects atten­dance data from hun­dreds of school dis­tricts on a dai­ly basis (one record/message per stu­dent, infor­ma­tion is col­lect­ed whether or not the child is in school).

A while back, they had a series of very snowy weath­er caus­ing the entire state to be off from school for five days in a row. When school final­ly resumed, all schools sent all 6 days’ worth of atten­dance data at the same time, amount­ing to sev­er­al mil­lion records in less than an hour.

Peak Peri­ods

Peak Peri­ods hap­pen in any indus­try. In sales, a spe­cif­ic prod­uct or com­pa­ny may receive excel­lent press in the media or on a TV show or movie. Like­wise, sales can be dra­mat­i­cal­ly affect­ed by law changes, requir­ing groups to pur­chase goods or ser­vices with­out advance notice. Sud­den inter­est spikes demand. Increased web traf­fic, high­er sales, and pres­sure to cre­ate and ship inven­to­ry all lead to poten­tial serv­er crash­es.

Nat­ur­al Dis­as­ters

Nat­ur­al Dis­as­ters hap­pen reg­u­lar­ly across the world, often with­out warn­ing. Just as a coun­try and its peo­ple are affect­ed by nat­ur­al dis­as­ters, so too are busi­ness­es and com­pa­nies.

When we con­sid­er busi­ness­es that ship prod­ucts from one loca­tion to anoth­er, a dis­as­ter in a region of a coun­try may inter­rupt the nor­mal chan­nels of prod­uct deliv­ery for a few hours or even for months. A com­pa­ny may have to reroute prod­uct deliv­er­ies from one loca­tion to anoth­er. Some­times this isn’t pos­si­ble, so a new loca­tion to han­dle the new traf­fic of prod­ucts is required. The new loca­tion would now be respon­si­ble for the ship­ping of its own usu­al amount of pack­ages, as well as the new traf­fic from the rerout­ed prod­ucts, all in an attempt to avoid down­time caused by a dis­as­ter. Once the storm has passed and repairs are under­way, the demand for new prod­ucts for these repairs will increase in order to bring the affect­ed areas back up to work­ing order.

As with the oth­er exam­ples, data traf­fic will increase for the loca­tions respon­si­ble for ship­ping all these prod­ucts, and the servers respon­si­ble for these demands can expe­ri­ence over­load­ing which may result in sys­tem crash­es that could cas­cade through­out the entire com­pa­ny.

Health-Relat­ed Emer­gen­cies

Dur­ing dis­as­ter sit­u­a­tions that would cause a greater influx of patients into hos­pi­tals, patient man­age­ment sys­tems can expe­ri­ence lag, caus­ing errors in patient pro­files. If sys­tems aren’t per­form­ing at the lev­el that they are expect­ed to, there could be an increased risk of HIPAA vio­la­tions dur­ing this time as well.

If a hos­pi­tal is at max­i­mum capac­i­ty, process­es need to be put in place for divert­ing patients to the next clos­est hos­pi­tal that is accom­mo­dat­ed to care for those patients. For that to hap­pen, these hos­pi­tals would need to be in sync in order to smooth­ly tran­si­tion patients from one hos­pi­tal to the oth­er or to bal­ance the patient load. The dif­fer­ent data points being filled in these respec­tive sys­tems would also need to be able to han­dle the strain of doc­tors and nurs­es across an entire health net­work using the same sys­tem to input patient data that must be main­tained at a high­ly accu­rate lev­el.

If not, this could neg­a­tive­ly affect health stan­dards at these hos­pi­tals. It could also cause prob­lems for the staff which their patients could end up pay­ing for with their lives.

A More Realistic View

Issues like these cause trou­ble for most or all of your servers at the same time, requir­ing that they all be addressed at the same time. If they are fixed one by one, dif­fer­ent results may hap­pen:

  • The first serv­er to be fixed could be auto­mat­i­cal­ly offloaded with all of the work­load that can't be han­dled by the remain­ing servers, caus­ing it to return to a failed state with­in a short peri­od of time.
  • A fix applied to one serv­er could begin a chain reac­tion that would make oth­er servers more dif­fi­cult to fix.
  • By the time the first serv­er is fixed, the oth­er servers may be past the point where rel­a­tive­ly sim­ple fix­es will be effec­tive.

An Enterprise Immune System

Dex­ter­i­ty is designed to be like an immune sys­tem for an enter­prise.

First, on a reg­u­lar basis, it per­forms many of the reg­u­lar main­te­nance tasks nor­mal­ly done by admin­is­tra­tors or sched­uled scripts, plus sev­er­al oth­ers that are specif­i­cal­ly designed to main­tain good per­for­mance of enter­prise line of busi­ness appli­ca­tions.

On reg­u­lar inter­vals, it sam­ples the health of the sys­tem, look­ing for devi­a­tions from nor­mal pat­terns of behav­ior. It checks log files, ser­vices, amounts of time the sys­tem has spent since the pre­vi­ous check per­form­ing cer­tain activ­i­ties, sta­tus of impor­tant sys­tem indi­ca­tors and more. If it notices a behav­ior pat­tern emerg­ing that indi­cates that peri­ods of unusu­al­ly high activ­i­ty may be approach­ing, it accel­er­ates the activ­i­ties that would ensure good appli­ca­tion per­for­mance to pre­vent prob­lems such as run­ning out of disk space, data­bas­es becom­ing less effi­cient, or tasks get­ting over­loaded. If the pat­tern revers­es (false alarm/rise in activ­i­ty was only short-lived), the sched­ule of reme­di­a­tion returns to nor­mal main­te­nance lev­els.

All of these things hap­pen auto­mat­i­cal­ly moments after the behav­iors change to all servers being impact­ed. With a typ­i­cal remote monitoring/staff res­o­lu­tion sce­nario, it could take an hour or more to locate the source of the prob­lem and mobi­lize staff to cor­rect it. Addi­tion­al­ly, once they know what the prob­lem is, they will always have a dis­ad­van­tage when the num­ber of machines start­ing to fail exceeds the num­ber of peo­ple work­ing to resolve the issue.

Ipseity

Ipseity — Identity and Application Role Manager

Overview

Ipse­ity is an inte­grat­ed appli­ca­tion that:

  • Col­lects infor­ma­tion about "objects" in your orga­ni­za­tion
  • Assigns and man­ages iden­ti­fiers for those objects
  • Cre­ates and man­ages Active Direc­to­ry accounts (if the objects cor­re­spond to peo­ple who need access to com­put­er resources)
  • Col­lects infor­ma­tion and keeps track of oth­er appli­ca­tions that run in the enter­prise
  • Assigns and man­ages appli­ca­tion roles in the appli­ca­tions and Active Direc­to­ry account assign­ments to those roles (used to imple­ment Sin­gle Sign-On)

Collecting InformationCol­lect­ing Infor­ma­tion
In medi­um to large enter­pris­es, "keep­ing track" of things, whether they are peo­ple, books, tests, stu­dent enroll­ments, doc­tors or even trucks, can be a for­mi­da­ble task.

Mod­ern enter­prise-lev­el, shared appli­ca­tions can have thou­sands to mil­lions of users or oth­er iden­ti­fied objects at hun­dreds to thou­sands of loca­tions. Each con­nect­ed appli­ca­tion can have many roles and a sin­gle user can assume sev­er­al of these roles in one or more appli­ca­tions.

For exam­ple, a Vir­tu­al Learn­ing Envi­ron­ment (VLE) could be host­ed at a region­al ser­vice cen­ter that man­ages the appli­ca­tion for 3,000 schools. In these schools, there are 1.8 mil­lion learn­ers, 200,000 teach­ers and about 2 mil­lion par­ents that need access to the sys­tem.

Because each of the orga­ni­za­tions have a line of busi­ness appli­ca­tion that man­ages these objects (such as a Stu­dent or Patient Infor­ma­tion Sys­tem) and since that sys­tem is attached to a con­nect­ed envi­ron­ment, Ipse­ity sub­scribes to the objects that con­tain the infor­ma­tion need­ed to assign iden­ti­fiers, cre­ates accounts and assigns roles in appli­ca­tions. This infor­ma­tion is fed into Ipse­ity auto­mat­i­cal­ly, and as changes are made, Ipse­ity receives them in real time.

Go to top
Assigning IdentifiersAssign­ing Iden­ti­fiers
Wher­ev­er there are many objects of the same type, iden­ti­fiers are need­ed. When­ev­er many objects of the same type are col­lect­ed and man­aged from many dif­fer­ent sources, glob­al­ly unique iden­ti­fiers are typ­i­cal­ly need­ed. Such is the case with peo­ple and Active Direc­to­ry accounts, but sim­i­lar needs exist for most man­aged objects that orig­i­nate from many dif­fer­ent source sys­tems (trucks, books, hos­pi­tal patients, weapons, etc.).

Ipse­ity has a built-in facil­i­ty for assign­ing iden­ti­fiers. This facil­i­ty is able to use col­lect­ed data as it arrives, and it can also assign iden­ti­fiers accord­ing to busi­ness rules set up at the time of con­fig­u­ra­tion. These rules:

  • First, test the data for qual­i­ty and com­plete­ness.
  • If the data is com­plete, then use the con­fig­ured "ID For­mat Rule" to cre­ate a new ID from exist­ing data.
  • Test to see if the pro­posed ID is already in use.
  • Use fall­back rules to cre­ate oth­er pro­posed IDs until a unique ID can be assigned.
  • Noti­fy con­nect­ed appli­ca­tions about the assigned iden­ti­fi­er.

Iden­ti­fiers can be in the form of num­bers, mix­es of strings and num­bers, for­mu­las involv­ing received data, or com­bi­na­tions of these.

Go to top
Managing Enterprise Active DirectoryMan­ag­ing Enter­prise Active Direc­to­ry
Con­tin­u­ing with our edu­ca­tion exam­ple, Ipse­ity inte­grates con­nect­ed appli­ca­tions by receiv­ing nor­mal events indi­cat­ing that objects have been cre­at­ed. These objects include:
  • Per­son­al demo­graph­ics and infor­ma­tion about where stu­dents attend
  • Per­son­al demo­graph­ics and job assign­ment infor­ma­tion for teach­ers and oth­er staff mem­bers
  • Infor­ma­tion about relat­ed con­tacts (par­ents) who also need accounts, so they can access infor­ma­tion about their chil­dren

Ipse­ity then uses that infor­ma­tion to cre­ate iden­ti­ties and man­age Active Direc­to­ry objects as need­ed. As it cre­ates AD accounts and groups, it has the abil­i­ty to pub­lish back to the zones and lis­ten­ing appli­ca­tions any of the objects con­vey­ing what the agent has done. This allows the lis­ten­ing appli­ca­tions to have enough infor­ma­tion to auto­mate Sin­gle Sign-on.

Ipse­ity also has the abil­i­ty to sub­scribe oth­er com­mon­ly pub­lished objects by line of busi­ness appli­ca­tions that pro­vide more infor­ma­tion about users who have accounts cre­at­ed for them.

For exam­ple, in edu­ca­tion, data may auto­mat­i­cal­ly be received con­tain­ing stu­dent infor­ma­tion about schools they attend, cours­es they take, and sec­tions of class­es into which stu­dents are reg­is­tered. Ipse­ity can use that infor­ma­tion to cre­ate Active Direc­to­ry groups, which can then be used to con­trol access to appli­ca­tions asso­ci­at­ed with a school, a course or a sec­tion of a course.

Some of Ipseity's oth­er fea­tures include:

  • Main­tain­ing attribute stores in prod­ucts such as Microsoft ADFS or Shib­bo­leth
  • Dis­cov­er­ing exist­ing Active Direc­to­ry accounts and groups to reor­ga­nize them to reflect the infor­ma­tion stored in your line of busi­ness appli­ca­tion and to cre­ate an Active Direc­to­ry Orga­ni­za­tion­al Unit Struc­ture that reflects your organization's struc­ture
  • Main­tain­ing an inter­nal data­base that reflects every­thing it con­trols in the domain: If the domain was ever lost or dam­aged, Ipse­ity could recre­ate it with­out human inter­ven­tion from its inter­nal data­base — with the excep­tion of cur­rent pass­words. Note: For secu­ri­ty rea­sons, Ipse­ity does not store cur­rent user pass­words in its data­base.
  • Man­ag­ing home direc­to­ries, file per­mis­sions, moves of direc­to­ry struc­tures, reset­ting of file per­mis­sions, etc.

Ipseity’s direc­to­ry man­age­ment fea­tures are busi­ness rule-based, so the pos­si­bil­i­ties are lim­it­ed by what is rea­son­able to do tak­ing into con­sid­er­a­tion the val­ue in doing the oper­a­tion and the time it takes to do the oper­a­tion.

Go to top

Managing Enterprise Applications and RolesMan­ag­ing Enter­prise Appli­ca­tions and Roles

In addi­tion to man­ag­ing the Active Direc­to­ry, Ipse­ity man­ages role-based appli­ca­tion access and stores all of its inter­nal data in a for­mat usable as an attribute store. Orig­i­nal­ly designed for use with the UK Shib­bo­leth stan­dard, then mod­i­fied to also sup­port OpenID (the stan­dard used in Aus­tralia), Ipse­ity uses a “con­fig­urable data­base schema plus meta­da­ta” mod­el for stor­ing account and role attribute char­ac­ter­is­tics.

When Ipse­ity starts, it reads the meta­da­ta, learns the basic struc­ture of the data­base and uses that struc­ture inter­nal­ly from that point on. This design allows Ipse­ity to sup­port fed­er­a­tion sys­tems such as ADFS or Shib­bo­leth with­out mod­i­fi­ca­tion to its core func­tion­al­i­ty.

Ipse­ity has its own user-lev­el user inter­face; the screens a user is allowed to see depends on his or her role in the enter­prise and what per­mis­sions he or she has for the Ipse­ity appli­ca­tion itself. Ipse­ity admin­is­tra­tors have the abil­i­ty to man­age appli­ca­tions and the roles with­in them. Every­thing else is con­strained by the user’s account char­ac­ter­is­tics. (Is this per­son a dis­trict employ­ee or a school employ­ee? What posi­tion does she or he hold there?). The data viewed, the audits searched and the appli­ca­tions that can be con­fig­ured will all be lim­it­ed by where the user is based and what their role is with the Ipse­ity appli­ca­tion.

Go to top

Provisioning User Roles in ApplicationsPro­vi­sion­ing User Roles in Appli­ca­tions

Typ­i­cal­ly, will have a pro­vi­sion­ing inter­face admin­is­tered either cen­tral­ly or from each of the organization's loca­tions wher­ev­er the appli­ca­tion is installed. As with our Verac­i­ty prod­uct, Ipse­ity sup­ports mul­ti­ple lev­els of admin­is­tra­tion pro­tec­tion:

  • Glob­al admin­is­tra­tor- access to all lev­els and all appli­ca­tions
  • Region­al admin­is­tra­tor — state-lev­el or oth­er mul­ti-loca­tion author­i­ty with per­mis­sion to admin­is­ter roles in appli­ca­tions that are avail­able at each of those loca­tions
  • Local admin­is­tra­tor: author­i­ty over a sin­gle loca­tion and appli­ca­tions installed for use at that loca­tion

The Ipse­ity itself uses sin­gle sign-on and rec­og­nizes the logged-in user as one of the above types of users. It also uses Ipseity's con­fig­u­ra­tion data­base to under­stand how the enter­prise is struc­tured and where appli­ca­tions are installed. Last­ly, it access­es the infor­ma­tion col­lect­ed through the inter­op­er­abil­i­ty inter­face to under­stand who might have access to these appli­ca­tions.

The fol­low­ing are the steps an admin­is­tra­tor would go through in assign­ing users (who have Active Direc­to­ry accounts) to roles in appli­ca­tions:

Appli­ca­tionRoleScopePop­u­la­tionsView UsersFil­ter, SortSelect UsersCon­firmCom­plete

Step 1 — Choose Application to be Provisioned

Every appli­ca­tion has its own user roles that dif­fer depend­ing on what the appli­ca­tion does. For exam­ple, a Vir­tu­al Learn­ing Envi­ron­ment might have roles for stu­dents, teach­ers, par­ents and admin­is­tra­tors while a trans­porta­tion sys­tem may have roles for dis­patch­ers, dri­vers and admin­is­tra­tors. Ipse­ity allows you to use per­son char­ac­ter­is­tics in your line of busi­ness appli­ca­tion to deter­mine which roles in the appli­ca­tion are appro­pri­ate­ly assigned.

So, the first step in pro­vi­sion­ing is to choose the appli­ca­tion to be pro­vi­sioned.

Click on the screen image for a larg­er view…

Step 2 — Choose Application Role

Each appli­ca­tion has a unique set of roles defined based on the func­tion­al­i­ty of the appli­ca­tion. In Step 1, we chose the Vir­tu­al Learn­ing Envi­ron­ment which has defined roles for Stu­dents, Par­ents, Teach­ers and Admin­is­tra­tors.

In Step 2, choose the role asso­ci­at­ed with this appli­ca­tion that is to be pro­vi­sioned. In this exam­ple, we choose to pro­vi­sion a Learn­er role in the Vir­tu­al Learn­ing Envi­ron­ment.

Click on the screen image for a larg­er view…

Step 3 — Choose Locations (Scope)

In this step, we choose at which loca­tions the appli­ca­tion will be avail­able from the com­plete list the user has access to. In this case, we are set up for a UK school envi­ron­ment, so a list of schools is dis­played, and we can select the schools that will have access to this appli­ca­tion.

Note: Stu­dent infor­ma­tion used in these screen cap­tures are for fic­tion­al stu­dent records ran­dom­ly cre­at­ed from lists of pop­u­lar last and first names. Any resem­blance to real per­sons, liv­ing or dead, is pure­ly coin­ci­den­tal.

Click on the screen image for a larg­er view.

Step 4 — Choose Populations

In this step, we nar­row down the poten­tial account pop­u­la­tion by char­ac­ter­is­tics of the dif­fer­ent types of users. Again, this is tak­en from an edu­ca­tion exam­ple where stu­dents are most often dif­fer­en­ti­at­ed by grade lev­el, teach­ers by title, and oth­er con­tacts by a rela­tion­ship type record­ed in their demo­graph­ic infor­ma­tion.

In our exam­ple, this Vir­tu­al Learn­ing Envi­ron­ment is to be used by stu­dents in grades 1–6. We may also choose to select par­ents from the sec­ond list (not doc­tors or sib­lings) and teach­ers from the third list (not busi­ness man­agers or clean­ers). By choos­ing these clas­si­fi­ca­tions and press­ing 'Next', the list of accounts we receive back will like­ly be close to the actu­al list we want.

Click on the screen image for a larg­er view.

Step 5 — View Users

On this screen, we see the list of peo­ple from the col­lect­ed data who match the loca­tion and oth­er cri­te­ria we spec­i­fied. This is a list of poten­tial users for the spec­i­fied role in this appli­ca­tion.

We may or may not want to assign all of them to this role — this is just a list of poten­tial users. In order to nar­row down the list even fur­ther, we now have sev­er­al oth­er con­trols as shown on the next screen.

Click on the screen image for a larg­er view.

Step 5a — Filter, Sort

In order to nar­row down the list fur­ther, two things can be done with the black col­umn head­ers:

  • The col­umn head­er can be dragged to the gray bar above it. This will cause the con­tents of the grid to be sort­ed by that col­umn.
  • At the right end of the col­umn head­ing, there is a fun­nel icon. If you press it, a "fil­ter" pan­el is dis­played. Using this allows you to fil­ter the val­ues in this col­umn.

Click on the screen image for a larg­er view.

Step 5b — Select Users

When the list of users to be assigned to a role in the appli­ca­tion has been select­ed, the 'Next' but­ton becomes avail­able. Click­ing on it will move you to the next screen for review and con­fir­ma­tion.

Note: On the right side of the win­dow are sum­ma­ry box­es show­ing how many items were select­ed at each step. If you want to go back, you can sim­ply click on one of these box­es, and you will be direct­ed back to that step. Keep in mind, if you do this, you will need to redo all of the steps fol­low­ing the one you chose.

Click on the screen image for a larg­er view.

Step 6 — Review and Confirm

Once you arrive at this screen, you can take one final look through the data (and go back and make changes if you need to), then press 'Fin­ish' to make the assign­ments.

Click on the screen image for a larg­er view.

Step 6a — Complete

Once the process has fin­ished, you will be giv­en a con­fir­ma­tion that the work is com­plete.

Click on the screen image for a larg­er view.

Go to top
Do NOT follow this link or you will be banned from the site!
en English
af Afrikaansca Catalanen Englishfr Frenchde Germanhi Hindiit Italianko Koreanpt Portuguesees Spanishsw Swahilizu Zulu
Instant SSL