Records

Each record describes one system, server, interface or facility.

Every change to a record is recorded with the person, the time and the channel. Confirmations such as Saved or Deleted appear only once EA Sphere has accepted the change; when it refuses one, the message says why. A request that gets no answer says that EA Sphere could not be reached. If EA Sphere cannot start, the page gives the reason in one sentence, followed by “Reload the page to try again.” Longer messages stay on screen longer, the messages one action produces are shown together, and a message asking you to try again, or saying that what you typed is still in the dialog, form or field, is replaced by what happens next, as is a progress message such as Saving… A message that would cover an open dialog's buttons appears above them. A dialog that opens on a group of options puts the keyboard focus on the one chosen.

When a save waits, fails or meets another person's change

EA Sphere decides every save on the server and confirms it only once it is recorded; when a save is not recorded, the dialog keeps what you typed and says why. EA Sphere makes one change at a time on your site, so changes made at the same moment are taken in turn and none is written over another. When two people change the same item, changes to different fields and to different list items are combined, and a save that would replace a value someone else changed in one of a form's main fields after you opened it is held back until you have seen that value. A delete EA Sphere has answered as done always stands. The details are under Changes made at the same moment.

Saves that wait or fail

Starting a degradation or an exercise; saving a degradation, a record, a work item or a completed tabletop exercise's review; recording a notice; and importing a CSV file all wait for EA Sphere: the dialog shows Starting…, Saving…, Recording… or Importing… and closes once the change is recorded; meanwhile its other buttons wait too, and selecting one says why. If the change is not recorded, the dialog stays open with what you typed and says why, once: EA Sphere stores each record, degradation or notice together with its history in one all-or-nothing operation, so one whose history cannot be written is not stored.

Saves written in parts, bulk add and CSV import

A save larger than one such operation, such as a CSV import or a work item that references many records, is written in several; if a later part is refused, what was written before it stays, with its history lines, and EA Sphere says the save was not completed and what of it was stored. Bulk add stays open until EA Sphere has recorded the records; when some were not, it says how many and keeps their names in the box, for example “Added 8 records. 12 records were not added: EA Sphere could not complete that request. Their names are still in the box; select Add to catalog to try again.” A name someone else added meanwhile is not kept in the box, for example “Fleet Tracker is already in the catalog: someone else added it meanwhile.”

After a lost answer, bulk add reads every record it may have added, however many names there were, before it says anything; when EA Sphere cannot be reached, it keeps those names in the box and says, for example, “It is not known yet whether Fleet Tracker and Route Planner were added: EA Sphere could not be reached. Their names are still in the box; select Add to catalog to check and try again.” Selecting Add to catalog again then checks each name first: one that was stored counts as added and leaves the box, for example “Added 2 records. Fleet Tracker and Route Planner were recorded the first time; nothing was added twice.”, and a record that was added and then deleted by someone else is not added again: “Route Planner was added, then deleted by someone else, so it was not added again.”

CSV import reports the import as not complete, with the number of records created and updated. A row for a record someone else deleted meanwhile is named, with what importing again does, for example “Import not complete: Branch App 07 was not updated because someone else deleted it meanwhile. 11 records created, 0 records updated. Importing the file again adds the deleted record back as a new record.” The import dialog, still open, then lists what else the import did under What this import did, at the top of the dialog, replaced at each import: the incomplete records it created, to complete from the catalog, with a record created only for a row whose record someone else deleted named only in a sentence of its own, for example “Gate Hub was created only for Branch App 07, which someone else deleted; delete it from the catalog if it is not needed.”; the values it could not use; and the values it added to the lists; the message adds “The dialog lists what else the import did.” If the dialog was closed meanwhile, the same list is shown in a dialog of its own. The record form says whether the record itself was saved and names the downstream dependents that were not. Colleagues see the stored part at their next refresh. Saving again finishes the save, writing no line twice, without overwriting a change a colleague made between its parts, and without creating again a record someone deleted meanwhile: EA Sphere says once that it was saved, then deleted by someone else, for example “Fleet Tracker was saved, then deleted by someone else.”

A work item stands even when some of its records' Referenced by or Reference removed lines could not be written with it: EA Sphere notes those lines with the save and adds them shortly afterwards, or at the weekly maintenance, each with its own time and person, in its place in the history.

The record form and downstream dependents

The record form also saves the downstream dependents you changed in it, for a new record once the record exists, and closes only when they are recorded too; if they are not, the dialog stays open and names them, saying whether the record itself was saved, for example “The record was saved, but downstream dependents General Ledger and Bank File Transfer were not saved: EA Sphere could not complete that request.” When the record itself had no change, the message begins “Downstream dependent General Ledger was not saved:”, followed by the reason. When EA Sphere cannot be reached to check them, the dialog says that it is not yet known whether the downstream dependents were saved; their history lines are written when the dialog closes, when a refresh in the next ten minutes or so finds them stored, or when a later save does.

The form says Saved and the record's name whenever the record or any of its downstream dependents was saved; a dependent someone else deleted before the save is named as not added, for a new record too and after the page has reloaded. When the only dependents not saved are ones someone else deleted meanwhile, the dialog closes and EA Sphere names them all at once as not added; a dependent you were removing or changing that was deleted needs nothing more, and one whose answer was lost is read from EA Sphere and counts as saved, with its history line, when EA Sphere has it. Saving again sends only what is still missing, so a change someone else made meanwhile stands, and the change history has no line for a dependent that was not saved. An edit form saves only the fields the person changed.

After a lost connection

A save the page sends again after a connection error, an update or notice included, is recorded once, never overwrites a change someone else made after it, and never brings back something deleted after its first attempt. When the save of a new degradation, exercise, record or work item gets no answer, the page reads it from EA Sphere at once and, if EA Sphere has it, says it was saved, for example Degradation started; when the save of an edit in the record form gets no answer, the form reads the record back at once and says it was saved when EA Sphere has the change. If that read cannot reach EA Sphere, the dialog stays open with what you entered and says that it is not yet known whether EA Sphere recorded it. After a dropped connection, the page reads everything again at its next check for changes (every 30 seconds while it is in view) that reaches EA Sphere, so it never keeps showing an edit that was not stored.

When the save of an edit in a degradation or work item dialog gets no answer, the dialog stays open and says the same; saving again first asks EA Sphere whether the earlier save was recorded and reads the stored copy. If the save was recorded and nothing has changed since, the dialog closes as saved; if it was recorded and something has changed, only that is sent.

EA Sphere keeps its note of each save for an hour: within that hour, an edit it has no note of was not recorded, and it is sent again, combined with what others saved meanwhile, like any save.

After the hour, EA Sphere looks for the save's own write in the stored copy: each save's writes carry a tag of the save, which names neither the save nor you. When the stored copy carries it, the edit was recorded: nothing is sent again, even if someone has since changed a field back, and their later change stands. Only when the stored copy no longer carries that write does it decide field by field: the edit counts as recorded only when every field it changed holds the value you sent, and it is sent again only when every one is still at the value it started from.

When neither holds, nothing is sent, and the dialog is drawn again from what is stored, keeping only your own changes; under a field you changed that someone else also changed, it shows the saved value, for example “Someone else saved this since: High.” or “Someone else cleared this since.” A support type that was on when you started, that you did not turn off yourself and that someone else has turned off since is selected again, with a note naming it, for example “Someone else turned off Vendor since. It is selected again to keep the details you entered.” Screen readers read each note with its field, and the focus goes to the first field with a note.

A change the dialog no longer has a place for, such as the stage, or an update typed for a degradation someone has resolved since, is named as not kept. EA Sphere says, for example, “It is not known whether your earlier save was recorded, and this degradation has changed since. Nothing was sent. The dialog now shows what is saved, with your other changes kept; where someone else changed a field you changed, the saved value is shown under it. The dialog no longer has a place for these changes, so they were not kept: Post an update (“Vendor engaged”); Stage (Mitigating). Select Save to save what it shows.” The part after the first semicolon appears only when there is such a field, and the sentence naming changes not kept only when there are any; otherwise the message says “with your own changes kept”, and when none of your changes could be kept, it says “The dialog now shows what is saved.”, without either phrase.

The record form follows the same rule after the hour; its message names this record, says “The form now shows what is saved” and ends “Select Save record to save what it shows.” If the degradation or work item has been deleted meanwhile, EA Sphere says so and sends nothing; and if EA Sphere cannot be reached, nothing is sent and the message says so. Adding a Jira work item again after a lost answer, in the Add a Jira work item dialog or the work item panel, also asks EA Sphere first, so a work item someone removed meanwhile is not added back.

Selecting the dialog's button again (Save record, Save work item, Start degradation or Start exercise) reads EA Sphere first; for an edit in the record form, saving again first asks EA Sphere whether the earlier save was recorded, deciding from the stored copy after the hour as described above, and continues from what was sent, so the change and its history line are saved once. If the first attempt was recorded but someone has since deleted the record, or removed the work item from EA Sphere, EA Sphere says once that it was saved, then deleted or removed by someone else, and creates nothing again. If the first attempt was recorded, a new record or work item is saved with only the changes you made since, as an edit of it, so changes others made to it meanwhile are kept and its change history shows one Created line, and a new record then opens. What is saved is always the latest you entered, even after an earlier try was refused; a degradation or recovery exercise start is handled as the next paragraph describes.

After a lost connection, a degradation or recovery exercise start, an update or a notice is read from EA Sphere before it is sent again, so it is never recorded twice; meanwhile the button shows that it is working and the dialog stays open. If EA Sphere cannot be reached to check, nothing is sent again, and the message says so and names the button to select to try again. If you changed it in the meantime, EA Sphere says what was recorded and keeps your changes in the dialog for you to save: a degradation started after all opens with your changes in it, and a mitigation work item you asked for is created once; an update posted after all appears among the degradation's updates, with your new text still in the field. For a recovery exercise start, a changed scenario, severity or participants is saved onto the exercise, and a changed system is explained, because the exercise was recorded for the system first chosen. After an update is posted, nothing posted with it counts as an unsaved change. A second click while a start or notice is being sent is ignored.

Two people at once

When two people edit the same record at once, EA Sphere combines their changes on the server: changes to different fields are all kept, and lists are combined item by item: a record's upstream dependencies, hosts, data types, business functions, modules, audiences and support types, a tabletop exercise's developments and a recovery exercise's steps. Each person's items stand with their history lines. Where both of you changed one of a form's main fields, such as a record's owner or a degradation's severity, to different values, the later save is held back until its author has seen the saved value, as described under Changes made at the same moment; where both changed another single value, such as a start or end time, a stage, a development's title or text, an objective's text or an exercise step's label, the later save stands, with its history line.

The same applies to work items, settings and exercises, and to EA Sphere's own changes to records, such as applying Jira's Done, moving a renamed value, or the weekly maintenance's corrections and its removal of references to deleted records: they take their turn with people's saves and are made on the record as stored, so each change, a person's or EA Sphere's, stands with its own history line. A field EA Sphere changed after you opened a form, other than by renaming its value, counts as changed by someone else.

A save that fails releases any record name it was holding at once, so someone else can create a record of that name, and never reverts a colleague's change; a save is never sent again from an earlier read over someone else's later save. A record deleted by one person is not brought back by another's save; EA Sphere tells the other person that the record was deleted by someone else, and only that, even when their save's answer was lost.

A reference to a record someone has just deleted, as a dependency, host or work item reference, is left out of the save, and EA Sphere says so; a host or upstream dependency the record form still lists after its record was deleted gets no history line when you save, and the weekly maintenance removes it; a degradation, recovery exercise or tabletop exercise cannot be started for a deleted record. A reference to a record someone else has just created under the same name is pointed at that record; for a work item, its Referenced by line is written in that record's history.

Deleting a record

Deleting a record is a single save that EA Sphere carries out on the server: it deletes the record's change history, degradations and recovery exercises, with their archived updates and notices, and removes the references to the record from every other record and every work item, including work items the person deleting it cannot see in Jira. EA Sphere removes the record itself first and its history and degradations after it, so a delete that stops part way never leaves a record without its history. A delete that stops before the record itself is removed is reported as not done, and the record stays with its history. One that stops after it, because storage refuses or time runs out, is reported as done: every open page drops the record and its degradations at once, and the weekly maintenance removes what is left of it, its degradations included, with any notices recorded on them (only a Jira administrator can delete a record whose degradations have notices), along with the references to it from other records and work items, as the delete would have, each record getting a history line by EA Sphere, for example “Upstream dependency: removed Dock Hub”. Until then, an edit to a degradation or exercise of that record is refused: “That record was deleted by someone else.” The Change log keeps the entries of any record that is still stored, and keeps a deleted record's history out of the Change log report while any degradation still names the record. Only a Jira administrator can delete a record any of whose degradations has notices recorded, archived notices included.

Every record delete, an administrator's included, checks the record's degradations again just before removing it: one saved for the record meanwhile is deleted with it, unless it has a notice recorded and the person deleting is not a Jira administrator, in which case the delete is refused. Tabletop exercises on the record are kept, and their reports show the record as deleted. If the delete is refused, nothing changes.

Tiers, verification and limits

Verify record confirms a record is current; EA Sphere records who verified it and the day, in that person's own time zone. Records are flagged when their tier's review interval passes; retired records are not due for review. The catalog exports its records as CSV, including each record's environment, hosting model and business functions.

A record holds up to 1,000 upstream dependencies, 200 hosts, 50 data types, 200 modules, 100 business functions, 100 audiences and 20 support types. A work item references up to 50 records, a recovery exercise has up to 300 steps, a degradation up to 100 incident work items, and a tabletop exercise up to 60 developments and 20 objectives, each development with up to 10 questions. A notice goes to up to 50 audiences and 50 individual addresses. A save that would go past a limit, including one made by combining two people's changes, is refused with a message; no list is cut short. Forms stop at each field's length, and the work item dialog and panel at 50 references; text longer than a field holds, from a CSV import for example, is shortened (a record name to 120 characters).

Changes made at the same moment

EA Sphere makes one change at a time on your site. Each save, the work item effects a page asks it to finish, deleting or replacing all data, each update from Jira and each part of the weekly maintenance reads what it changes and writes it before the next change begins, so changes made at the same moment are taken in turn, each on what the one before saved. The second normally waits a fraction of a second. A save that cannot begin within about eight seconds, because another change is still being made, writes nothing: the page sends it again by itself for about half a minute, showing Saving…, and only then says “EA Sphere is finishing another change. Yours has not been saved yet; try again in a moment.”, with what you entered still in the dialog. Deleting all data, and replacing it with the sample data set, are sent again in the same way.

When two people change the same item, EA Sphere combines their changes, as described under Two people at once: changes to different fields are all kept, and list items, such as a record's data types, modules, audiences, hosts and dependencies or a work item's references, are combined item by item. When one of the fields listed in the next paragraph was changed after you opened the form, by someone else or by EA Sphere, and your save would change it to a different value, nothing of your save is stored. The form keeps what you entered, shows the value now saved under that field, with a Use the saved value button, and says, for example, “Owner was changed after you opened this. The saved value is shown under the field; save again to keep yours, or use the saved value.” Saving again keeps your value; selecting Use the saved value puts theirs back in the field, so it stays.

The fields compared in this way are a record's name, type, owner, primary contact, version, in-service date, planned retirement date, vendor end of support, support notes, recovery tier, environment, hosting model, recovery sequence step, vendor, vendor support site, vendor support phone, contract reference, support portal, support contact and on-call line; a degradation's or recovery exercise's severity, reason or root cause, related change, summary, scenario and participants; a tabletop exercise's title, type, scheduled date, facilitator and participants; and the title and due date of a work item kept only in EA Sphere. Start and end times and stages are not compared: the later save stands, with its history line. Ending a degradation or an exercise has its own answer.

A degradation is resolved, a recovery exercise ended and a tabletop exercise completed once. When someone else did so first, you are told, for example “Someone else already resolved this degradation.”, and nothing of your resolution or end is recorded. An open degradation dialog then shows the degradation as resolved, with its end and duration and without the stage or the Resolve degradation button, keeps what you typed, and says “Someone else resolved this degradation. What you entered is kept: select Save to add it to the resolved degradation.” An update typed there is posted at the Resolved stage. What happens to the review notes of an exercise someone else ended first is described under Recovery exercises and Tabletop exercises. While a dialog waits for its change to be recorded, all its buttons wait too, and selecting one says why.

When an administrator removes a recovery tier or a communication audience in Settings while your record form is open, the form stops offering it once the page has read Settings again; if you had chosen it, it is shown with “(removed in Settings)” after its name. A save that still sends it keeps the record's recovery tier and leaves the audience out, saves your other changes, and names them, for example “Tier 9 was removed in Settings, so Payroll keeps its recovery tier. Finance leadership was removed in Settings, so it was not added to Payroll. Your other changes were saved.” A tier or audience that a record uses cannot be removed in Settings; the message names the records.

A delete EA Sphere has answered as done always stands, whole: the deleted item is never stored again, and its name can be used again by one record only. A save of something deleted meanwhile is refused: with “That record was deleted by someone else.” for a deleted record and for a degradation or exercise of it; with “That degradation was deleted by someone else.” for a deleted degradation; with “That exercise was deleted by someone else.” for a deleted recovery exercise; with “That tabletop exercise was deleted by someone else.” for a deleted tabletop exercise and the notes written for it; and with “That work item was removed from EA Sphere by someone else.” for a deleted work item, a Jira work item included. A reference to a record deleted meanwhile is left out of the save, as described under Two people at once. When the same Jira work item is linked to two different EA Sphere work items at the same moment, the second link is refused: “OPS-3 is already in EA Sphere. Edit it there instead.” A change EA Sphere has confirmed as saved is not lost afterwards, and no degradation with a notice recorded is left on a deleted record once the weekly maintenance has removed what a delete that stopped part way left.