Veonics® Portal Elements

The Veonics® Portal is a cloud-based platform used for managing photo identification information, printing, and issuance. This article provides a technical overview of its element structure, flow, and functionality.

The Veonics Portal is entirely built on PHP and uses a MySQL database to manage most of the information, except the photo binaries, which are kept separately and accessed through a “service provider”.

Currently, there are two service providers:

1. simple file system (images are stored as simple files in a secured folder in the host server)
2. S3 (images are stored in a secured S3 bucket on AWS).  

While the Veonics® Portal operates as a web-based identity management system IDMS, the functionality extends far beyond traditional badging applications.

In the Veonics® Portal, several entities handle the identity data, as the diagram below shows below.  

• Core elements (in blue) are the primary entities to hold the identity and photo information and define how it will be interpreted.  
• Support elements (orange) complement the core elements and are used for specific operations. These elements are described in more detail in the following sections.

Core Elements

These elements implement the primary functions of handling information and photo information.

Card Record

The central element for holding identity information is the Card Record object.  In Veonics® Portal, Card Records (cards) are always part of a Record Properties, which defines the common properties of these cards, including the fields captured for each card.  Cards have a lifecycle defined by a workflow described below.  Besides the specific information fields, each card has a globally unique identifier and other system fields used to trace its status in the workflow, the date of creation, and the date of the last change.  If the Record Properties in a card are defined to support this function, each Card object will be attached to a Virtual ID (vID), access to which is controlled by a specific policy, as discussed below.  Access to a Card Record is restricted to users in organizations with scope over that Record Properties, as discussed below, and even then, individual fields may be protected by additional permissions.

Photo

While photos are logically considered as another field in a Card Record object, they hold a privileged place in the Veonics® Portal and have a lifecycle independent of the cards to which they are linked. In fact, a single photo may be shared by multiple cards, typically in the same Record Properties, but potentially across Record Properties and even organizations.  When originally brought into the Veonics® Portal, photos may be linked only to the Record Properties into which they are uploaded and later tied to a specific card.  This is typical of the scenario where photos are uploaded in bulk and later matched to cards by using the original filename and checking it against a pattern formed by fields in the card record (for instance, last name, followed by an underscore, followed by the initial of the first name, and the “.JPG” extension).  Photos may also be brought into the Veonics® Portal by using a CELLfie™ request, which provides a token-based link that a person can use to upload or capture their photo.

Photos are typically not used “as-is” but rather validated against a specified Standard to ensure they possess the desired quality attributes for an ID.  This validation may require certain manipulations (cropping, red-eye reduction, contrast, and other filters) that alter the original image to make it compliant.  This establishes a simple workflow, described below.  The policy in Veonics® Portal is that the original photo is always kept intact, so every time the image is modified, a new version is saved with a pointer that allows the Veonics Portal to trace the photo’s “pedigree”.

When a photo is brought into a Portal, it gets cryptographically stamped.  If the image is exported, it will retain this stamp, which allows a system user to verify its authenticity.

Record Properties

The Record Properties defines several common characteristics of a set of Card Record objects. This includes the Standard used to validate the Photos in the Cards, the linking of the vID Design and policy that controls access to vID’s for Card Records in this group, and the Record Setup that defines the fields available to Cards in the group. It also identifies the organizational scope of the Card Records and provides a placeholder for additional custom fields, which are not handled by the system but are provided as a convenience for the user.  Record Properties have a very simple workflow, described below.  In addition to this, Record Properties may optionally be assigned to a “Family”.  Family members belong to the same organization sub-tree and typically share the same Record Setup.  When a card is part of a group that is, in turn, part of a family, it is possible to “move” the card from one Record Properties to another one within the same family.

Record Setup

The Record Setup defines a list of fields available for use in a card record and the policies and characteristics of that field.  This enables the Veonics® Portal to have a uniform way of handling records with a different structure.  Record Setups have a simple workflow, too, but the activation operation in the design is particularly important since it generates all the scaffolding within the Portal to handle the variable structure that having a design affords.  

Note, Record Setups in Veonics® Portal are “flat”: each field is presented in the assigned Record Properties and the data is saved in its own table and can not be shared by other Record Setups assigned to other Record Properties. The can only be moved using the Family feature. Also, Record Properties are recommended to be among multiple Record Properties within the same visibility hierarchy, especially if they have the same requirements and configuration.  This makes it easier to fine-tune and effectively share badge template designs.

Field Properties

The following properties define each field in a design:

• Field:    this is what defines the semantic characteristics of the data being stored in the field.  It is selected from a list of predefined fields, containing most common data elements (such as first name, last name, employee number, position, etc.), as well as a number of “generic”, all-purpose fields of specific data types.  Not all fields are equal: some, less frequent ones, are implemented in a way that imposes a slight performance penalty, in order to maximize flexibility.  These are clearly marked, and it is recommended to limit the use of those only to situations where it is truly necessary.  By the same token, though, it is important to choose the field that best fits the ¬meaning of the information being stored.  For instance, if storing the title of an employee, it is better to choose the “position” field rather than “generic text 1”.
  Caption: this is the label that will be used to identify the field for the user in the Portal.  It is otherwise not used by the system, so there is entire freedom in choosing this value according to the user’s preference.  For instance, some organizations may have a particular designation for an employee code, such as “Partner Number”, and it is preferable to use what they will be most familiar with.
• Alias: this is the name that will be used inside the Portal and associated products to identify this field.  There are, therefore, some basic rules for choosing this value, but usually the default will be enough.
• Order: this only identifies the relative position on which the field gets displayed among other fields in the card, and is only relevant for display and user convenience: the system does not rely on this property.
• Visibility: this is a critical property that defines the rules to grant access to a field.  The possible values are:
  • Public: any person, whether a user or not, will be able to view this field.  In particular, this applies to screens in the Portal that do not require a proper user login, such as CELLfie™, vID viewer and photo verifier.  Only non-sensitive information should be marked this way.
  • Normal: these fields are available to any user who has scope over this card.  It is recommended for most non-sensitive information.
  • Management Tier 1 and 2: these fields are available only to users who have been granted a specific permission to view fields with those visibility levels.  They are meant for fields that are not considered PII but should also be restricted only to certain individuals.  One example of this could be the person’s salary or paygrade.
  • Private: these fields have the highest level of sensitivity, typically for full-fledged PII.  In order to access these fields, not only do the users need to have a specific permission, but they are not displayed by default: the user must mark the ones they require, and click on a button to retrieve their values, adding a note to justify the need to access them.  This access is also logged for audits.
• Critical Identifier: this optional property identifies this field as one of up to 10 critical identifiers.  These are particularly important when synchronizing external sources, either via VCDB or manual file import.  The use of critical identifiers is described in more detail below.
• Display on List/Search Enabled: these property determines if there will be a column for this field when looking at a list of cards in the group, and if there will be a specific search box on this field.  It is recommended to limit this to those fields that are most commonly used to identify a particular card.  Having too many fields will take too much screen real estate, and will also have a performance impact.
• Catalog: if this property is selected, when editing a card, the user will be presented with a dropdown of values taken from a Catalog (described below), rather than allowed free entry of the values.
• Generation: this option is used for fields whose values are not entered by the user, but rather generated by the system using a specified pattern.  There are several configuration options for generation, but they are beyond the scope of this document.

Critical Identifiers

When importing or synchronizing records, if there are critical identifiers defined for a Record Properties design, a new record is created only if none of the existing records’ critical identifiers match the corresponding identifier in the imported record.  If a match is found, instead of creating a new record, the matched one will get updated.  Up to 10 critical identifiers may be defined, and each of them can consist of one or more fields.  For a critical identifier to match, all the values of the fields in the identifier must be equal.  A record is considered matched if at least one of the critical identifiers is found to be matched.  This design allows a great deal of flexibility, especially when synchronizing data from different systems, which may use different elements for uniquely identifying a record.
Consider the following scenario: the table below lists some fields in a hypothetical Record Setup, marked with the assigned critical identifier they belong to, if any.

Assume the following data is already present in the Record Properties.

And consider the following data is being imported.

The resulting Record Properties will be as follows.

• The first import record, John Doe, matched ID 8 on critical identifier 2 (Department=H.R., Dept. Code=8), and Access Badge # was updated to A13456Z.
• The second import record, Jane Samplename, matched ID 9 on the critical identifier (EmployeeID=14663).  No data was updated since the only field that changed, Department, was blank in the import set.
• The third import record, Alex Perez, matches the name of ID 10, but the first and last names are not critical identifiers (it is usually not a good idea to use names as critical identifiers since there is the possibility of homonyms).  There is no Employee ID or Access Badge #, and, while in both cases, the Department is “H.R.”, Dept.Code is 9 in the card record and 11 in the import, and a match on both is required to meet critical identifier 2, which is compound, so a new/additional record gets created, ID 19.
• The fourth import record, Max LeJeune, also finds no match on any critical identifier, creating a new record, ID 20.

Template Designer

The Template Designer specifies the graphic layout of a virtual ID: which elements are displayed and where, and what their visual properties are.  Badge designs are created with the Template Designer and can include advanced features such as conditions on individual fields or a group of fields, elements calculated on a formula based on existing fields, barcodes, QR codes, and support for encoding and/or reading of magnetic stripe, with placeholders for the future addition of support for RFID and chip.  When a template design is assigned to a Record Properties, cards in that property automatically acquire the ability to be rendered as Virtual ID's to be displayed on common browsers.  One of the most important features of Designer is that designs can be rendered in real-time to reflect changes in the status of the card or of individual data elements.  These, in turn, can be used to trigger conditions, such as to make particular conditions visible, for instance, an expired, stolen or inactive card, or, on the other hand, the acquisition of an accreditation to perform CPR by an emergency responder.  Also, cards in a group supporting vID’s gain the possibility of being printed using vPQM.

Organization

Organizations are key to separating visibility and sharing elements in the Veonics® Portal. Organizations follow a strictly hierarchical scheme: every organization has a parent, except the system-defined “Root”, and can contain zero, one, or more “child” organizations.  An Organization may be assigned quotas on multiple properties and have a default language, plus a set of user-defined custom fields provided for user convenience.  Users are assigned to an organization, and this determines which Record Properties are accessible to this user, as discussed below.

User

A user is an account, whether of an individual or a system, that is granted access to the services of the Veonics® Portal.  A user should always have an assigned e-mail address which is used for notifications.  As mentioned above, a user is assigned to an organization, which determines the user's visibility.  A user is also assigned one or more roles and may be granted additional individual permissions, determining the operations the user may perform in Veonics® Portal.  The user may be able to control additional options, such as the predetermined length of lists and the language used in the Portal.

Support Elements

These elements are used to support the implementation of the platform operations in conjunction with the core elements.

Standard

A Photo Standard is a collection of rules that a photo is expected to meet to comply with the quality requirements for use in a card of a particular Record Properties.  Standards are, like most elements, assigned to an organization, and may be shared up or down the chain.  For the most part, standards are defined at the global level, but it is possible to define standards that are only accessible to a particular organization and its descendants, for private, generally stricter, rules.  Rules in a standard can fall into two broad categories: system-enforced, or manual.  Manual rules are simply text entries that a user, manually validating the photo, must read and visually determine if the photo (or photos) comply with that rule.  This is generally used for attributes that cannot be reliably validated in an automated fashion, such as absence of headgear and piercings, uncovered forehead, image crispness, etc.  On the other hand, system-enforced attributes contain additional attributes which are used by the Portal to determine if the photo is acceptable.  The most critical, and only mandatory, rule is the aspect ratio.  Two other optional rules can control the minimum and maximum resolution of the photo.  A photo below minimum resolution would typically print too grainy, while a photo with too high resolution takes more storage space and imposes a performance toll on operations that access it.  A final rule for coverage uses multiple attributes to generate an overlay that should frame the face in the photo, and is also used to drive the automatic cropping when supported.

Catalog

Catalogs are simply lists of value pairs, one of them serving as a code, and the other as the description, although it is not unusual that both values be identical.  When selected for a particular field in the Record Setup, users editing data will be presented with a dropdown to select the value from the list.  Catalogs may be created manually, imported from a simple Excel or CSV file, or generated based on the data already in a particular Record Properties.  Catalogs are also assigned to an organization and may be shared up and down the chain.  At the root level, it is usual to have some common catalogs, such as “Gender” or “State” (in this case, for instance, the typical code would be the 2-letter post office designation, such as “FL”, and the description would be the actual name, “Florida”)

Queue

Queues are used to control printing from the Portal using vPQM.  A card that has been approved may be placed in a particular queue, and a vPQM instance connected to that queue will be able to retrieve the card, print it, and mark it as printed.  While in a queue, a card may be put on hold, so it remains there but will not be printed until the user decides to, or may be moved to a different queue.  This allows for a very flexible mechanism for managing printing.  While queue management follows the familiar hierarchical scheme, users allowed to print to a particular queue must be specifically assigned to it.  There is a particular variant of queues:  proofing queue.  When a card is printed from a proofing queue, it does not get marked as printed, but rather is returned to the “approved” status.  Also, when printing from a proofing queue, vPQM will not print cards individually, but rather print to a letter-sized page, up to 8 images (with double-sided cards taking two images printing side by side).  This allows the printer to create a proofing run in inexpensive paper or, better yet, generate a PDF document to allow the end customer to review how the actual cards will look and make corrections while it is still possible to do so cheaply.

Token

“Token” is a very generic concept and there are several different scenarios under which they are used inside the Veonics platform.  In general, they consist of a long chain of pseudo-random numbers and letters, and typically have a defined validity period.  Some of the current scenarios for token use include:

• CELLfie™ Request:  In this case, the cardholder receives an e-mail message with a link that includes the token.  By following the link, the Portal can determine which card should the photos (and data) be linked to.  The assumption is that the delivery via e-mail to a known address minimizes the risk of the request being used by someone other than the intended individual.
• vID Policy: a vID may be protected with a policy that requires a token.  In this case, the link to access the vID will include the token.  Anyone with the link will have access to the vID, but it falls in the hand of the cardholder to control access to this link.  The main protection, in this case, is not so much controlling access to the vID but to prevent an unauthorized party to brute-force gaining access to a vID by simply testing consecutive card ID’s.
• User API Token: these tokens are generated, typically with a short validity period, in order to grant access to the Portal services without the need to pass credentials (username and password) on every single call.  This is most critically used by the vID Mobile App.

Station

In the Veonics® Portal, a Station is a logical system, typically a computer, authorized to remotely invoke a series of services associated with a recognized application.  A Station must have a designated system user, whose account is used to determine the scope of the access and the permissions to execute specific operations.

Import/Export Data Definitions

An Import Data Definition is used as a template to map elements in an import dataset to the fields in Record Properties, Record Setup.  Once the definition is initially configured, the user can import information from additional datasets without creating a new mapping, provided that the new datasets follow the same structure as the initial.  Currently, import data definitions accessible through the Veonics® Portal support Excel files, delimited or fixed-width column text files, or XML files with a particular two-level structure, while VCDB adds support for imports coming from a database query.

Export Data Definitions operate almost in the same way, but in the reverse, selecting which fields from the records will be exported and what the captions will be for the corresponding columns.  Currently, exports generate only CSV or Excel files.

Notification

A particularly powerful feature of the Veonics® Portal is the ability to dispatch notifications to predefined targets when certain events occur within the system.  Currently, all notifications are done via e-mail messages, although the framework would allow for the inclusion of alternate delivery mechanisms.  The subject and body of the e-mail are controlled by a notification text, depending on the specific event that triggered the notification, and that text can include a substitution of certain fields, which allows for the personalization of those messages.  Also, alternate versions of the text for the same event may be assigned to different organizations, allowing text customization to be sent.  If a particular organization does not have custom text assigned, the Portal looks for text on the parent organization, and so on, until the top of the hierarchy, with the default message, is reached.  E-mail notifications may use most HTML elements, including embedded images, to allow for a richer message.

Element Workflows

Implementing a workflow for key element objects is a very important feature of the Veonics® Portal. A lifecycle comprises multiple statuses and is implemented as a state machine.  At each stage, only certain actions are admissible, and some of those actions trigger a change in the status.  Element objects may be active or inactive in most cases and alternate between those conditions as needed.  Objects are generally not completely deleted, even when no longer useful, because audit traceability would be invalidated otherwise.

Other objects, however, have more complex lifecycles.  The most common of those workflows use three states: New, Active, and Inactive.

• The “New” state is typically a scratchpad state where the object is still not completely defined and ready for use;
• The “Active” state means that the object can be used normally;
• The “Inactive” state means that the object should no longer be used but is retained and remains valid for current objects already using it.  

“Forward” transitions (from “New” to “Active” to “Inactive”) are considered normal, while “reverse” transitions are considered exceptional and are protected by special permissions because they can have additional implications and side effects.

Card

The Card object has, by far, the most complex workflow of all, as depicted in the diagram Above. The complexity is better understood by breaking down the workflow into parts that apply to certain conditions.  The basic flow, when everything goes as usual, is the following:

In this case, a New card is created, and while at this state, users can make any change to the object’s fields.  Once all data is correct, the record gets Approved, meaning it is ready for printing. If the card is printed via vPQM, it gets Enqueued (placed in a specific Queue for printing), from which it is marked as Printed once vPQM has produced the physical card.  If the record is being printed externally, it should be manually marked as Printed.  This would be the normal end of the card’s lifecycle.

Of course, sometimes things may not go as smoothly, reflected in adding certain actions and states, as presented in this augmented workflow version.

In this flow, a New card may be wholly deleted.  An Approved card may be reopened to make changes to the data. An Approved, Printed, or Enqueued card may be inactivated if no longer relevant or valid.  An Inactive card may be reactivated.  A Printed card may need to be reprinted, typically because the printout was somehow faulty.  For the most part, these are exceptional transitions, protected as such.

The final pieces of the workflow are put into place to account for what may happen after a card has been Printed.  A card may be marked as Shipped: this is a “convenience” status, not interpreted by the system, but potentially relevant to users in a service bureau setting.  A card may also be reported as Lost or Stolen, in which case it is no longer valid but is potentially still at large, and a person trying to use it for identification suggests the possibility of fraud.  Finally, a card may need to be reissued, usually as a replacement for an expired, lost, or stolen card, in which case the current card gets marked as having been superseded and a new card record is created with the same data, and linked to the original one for traceability.

Photo

Photos themselves do not really have a workflow.  What does have a workflow is verifying those photos against a standard for acceptable use in a card.  Therefore, there is a simple workflow for a card and the linked photo.  Initially, a card is Missing a photo.  Once a photo is linked to the card record, the status will show it as Pending Validation against the card’s standard.  If the photo is found to be in compliance with all the rules in that standard, it becomes Accepted.  Sometimes, to achieve this compliance, the user must perform certain manipulations, such as cropping, on the photo.  If it is determined that it is impossible to manipulate the photo to comply with the standard, the photo may be marked as Unacceptable.  This validation against the specified standard becomes a property of the Photo object itself, so if, in the future, the same Photo is used (for instance, when re-issuing a card) in conjunction with the same standard, a new validation operation is no longer required.

Record Properties (legacy Card Group)

Record Properties have a lifecycle that is a variation of the common New/Active/Invalid pattern.

 
In this case, the additional Locked state indicates that the Record Properties is still active and all cards in the group are still valid, but no further changes to the Record Properties are allowed. Cards in the Record Properties may still make any post-Printed transitions, but no new cards may be created, modified, or printed.  If a card in the Record Properties needs to be modified, initially,  it must be moved to a different, unlocked Record Properties in the same family or re-issued into another such Record Properties.  The main reason for doing this is to provide “closure” to Record Properties to make them manageable, but the use of this facility is entirely at the customer’s discretion, and there is nothing inherently invalid with leaving a Record Properties perpetually in the Ready state.

Record Setup

Record Setups follow the familiar New/Active/Inactive pattern.  However, only Active Record Properties designs are available for use in new Record Properties.  Furthermore, the “Activate” transition implies that it generates all the scaffolding the Portal requires for this design.  While there are exceptional, protected actions to allow a design to be re-opened, this should be done with extreme caution, making only the necessary changes and re-activating immediately, at the risk of introducing extraneous behavior.  Even with necessary changes, the privileged user should be aware that certain properties, such as the field alias for current fields in the design, may already be used, for instance, in a vID Design or for synchronization processes in VCDB, which may now be rendered invalid and cause unexpected problems.

Template Designer

Template Designs actually have three separate attributes that control their availability.  

• One is the common binary Active/Inactive attribute: only Active designs can be selected for use in a Record Properties, but they cannot be modified, except with special permissions.
• The second attribute, Available/Unavailable, controls whether the badge template design will be listed in the Template Designer and is the closest equivalent to deleting the design.
• The third attribute is related to the approval of the design by the customer.  Once a design has been Approved, further changes to the design will remove this approval.

User Security and Visibility

Security is a critical component of the Veonics® Portal.  Servers and software code are subject to industry best practices to ensure that data in the platform is adequately protected.  Within the application itself, it was also a key concern to ensure that individual users only have access to the functions and data they are entitled to.

Access to operations is protected by a comprehensive set of permissions, themselves protected for higher-level permissions.  Given the sheer number of permissions (over 200 and growing), to keep them manageable, they are grouped logically and presented in a tree and also grouped into Roles that correspond roughly to what is required for typical use cases and granted as a block. This scheme provides finely granular control over what a user is allowed to do within the Portal. The effective permissions granted to a user also impact what the Portal UI presents to the user, so only operations and pages available to the user are displayed.

Control of visibility is another important consideration.  This control is implemented through the use of Organizations, which delimit the scope of a user in a strictly hierarchical fashion: a user belonging to a particular Organization has access only to the objects in that Organization and in all others that are descendants of it.  This means that access to identity records in Card objects is segmented so that they are shielded from other organizations that are not ancestors of the organization to which they belong.  To clarify this, consider the following example.

• Root
  • Partner 1
    • Company 1
    • Company 2
      • Division A
      • Division B
  • Partner 2
    • Company 3
    • Company 4

In this case, a user belonging to Root has access to all records. A user in Partner 1 (Veonics Portal Dealer "Partner")  has access to records in Company 1, Company 2, and the latter’s Divisions but not to any record from Partner 2.  A user in Company 1 can only access records in Company 1 but not in Company 2.  A user in Company 2 has access to records in Company 2, as well as in that company’s Division A and Division B.  A user in Division A or Division B can only access its own records but not those in the other.

In the case of other objects, such as Standards, Record Setups, vID Designs, and Notifications, the protection is somewhat different: a user with the right permissions in a given organization has the ability to manage these objects for that organization and its descendants, but is also able to use (but not control or edit) objects in an organization that is an ancestor.  In the previous example, a Division A user could create a Record Properties using a Design that belongs to Division A, to Company 2, to Partner 1, or to Root, but would only be able to modify designs that belong to Division A.  Note that the objects to which this kind of “sharing” applies are only definitions, or meta-data, not actual data, so there is no compromise of privacy.  The purpose of this approach is to provide for reuse of well-defined objects, a practice that is encouraged.  A Partner can create a finely-tuned Record Setup and use it in all, or most, of the Record Properties in any of its customers.  An organization can define its own photographic Standard and enforce it in all associated divisions. 

Integration Mechanisms

The capability to integrate with other systems is a critical feature of the Veonics® Portal.  It allows the platform to remain focused on its core competencies while allowing new products, by Veonics or third parties, to use the services that form the nucleus of the Portal, extending the platform's possibilities.  To provide this capability, Veonics® Portal has a Veonics Credential Database (VCDB) integration set of tools: one VCDB APIs based on mature, industry-standard protocol: a JSON-based REST API.  The second is the VCDB SFTP tool.  Both are considered permanent work-in-progress: while offering a core set of services that fulfill current needs, they offer a structure to add new services to cater to future needs.    

No API provisions exist for “pushing” information to external systems. When needed, we enable our SFTP process.

It is important to note that the robustness of the APIs, as they currently exist, has been proven by the fact that the current companion products, VCDB, vPQM, and the vID Mobile App (disabled), all use them as their exclusive mechanism for communicating with the Portal.

Deployment Options

The Veonics® Portal, as previously discussed, consists of a set of PHP scripts, a MySQL database for storing the data, and a configurable service provider for storing images.  Currently, there are two separate instances of that setup:

1. Quality Assurance (QA)
2. Production

Developers commit changes to the source control tool (Git); from there, they can be deployed to QA by executing a simple script.  Once the changes have been certified to work as desired and not cause unwanted side effects in the QA environment, another script can push these changes into Production with minimal or no disruption of operations.  Both instances are currently hosted in the AWS cloud platform, with the database providing geographic redundancy.

The above-mentioned deployment process is stable and robust and is not the only option for setting up the Veonics® Portal.  Different configurations may be set up to cater to the specific needs of customers of Veonics or its partners.

Shared Instance, Shared Database

(the only option in use)

This scheme is being used today for production: there is a single server instance, and all the customers’ data resides in the same database, where access is protected in a hierarchical fashion, as discussed above.  While all customers are sharing these resources, current and foreseeable workloads are nowhere near exhausting these resources, and the AWS platform provides simple mechanisms for upgrading, should it become necessary.  The main advantage of this approach is its simplicity, particularly for maintenance, which makes it easy to keep everything up to-date and finely tuned by centralizing these operations.  Unless there are overriding reasons, it is recommended that new customers continue to be enrolled in this scheme.  

The current address for this instance is https://portal.veonics.com.  Even within this scheme, it is possible to set up multiple configurations, for example;

• Sub-sub-domains
  • https://partner.portal.veonics.com
• Aliases
  • (https://portal.veonics.com/partner/)

While being functionally equivalent and accessing the same database and storage, it may have a custom “skin”.

Shared Instance, Dedicated Storage

(only for large project consideration)

In this variant of the above, there is still a single server instance, but the storage, both the MySQL database and the service-provider-mediated storage for photos, are placed in separate, dedicated storage.   Since there is a single server instance, it is necessary to identify the configuration used to access the dedicated database, and for that, it is essential to use one of the approaches described above (sub-sub-domain, which is the recommended method or alias).  The key advantage of this scheme is that the customer’s data is kept entirely separate from that shared by other customers, which may serve to assuage some customers’ concerns about privacy.  In addition to this, having dedicated storage enables, at a cost, the possibility of offering other services afforded by the cloud platform and even switching to a cloud provider other than AWS, which certain customers might favor.  This is already a possibility for the MySQL database, although it will still require additional development for the service provider that controls the storage of photos.  Finally, for particularly sensitive customers, there is the possibility of allowing them to contract and pay for the database and file storage directly rather than using Veonics’ AWS contract, although in that case, Veonics should still get fully-privileged access to that server for maintenance operations.  The main complication of this approach is that maintenance operations that affect the database must be performed separately for the dedicated database.

Dedicated Cloud-Based Instance and Storage

(only for large project consideration)

A step above the previous scheme, this uses an entirely separate server instance to host the PHP scripts.  The clear drawback of this approach is that all maintenance operations, particularly upgrades, must be performed separately, which adds significant overhead for the Veonics Portal development and maintenance team.  In this case, however, the instance is entirely separate from the Portal Production server and so may use its own domain designation, include additional services from the cloud provider (such as AWS’s Elastic Beanstalk, to support load balancing and robust spawning of multiple instances to support higher load levels) and greater administrative autonomy for the customer.  Costs for this option are naturally much higher than the shared options.

On-Premises Instance and Database

(only for large project consideration)

The ultimate solution for sensitive customers is to have an on-premises instance of the Portal, usually encapsulating the database server and storage service provider.  eXpress badging can provide a fully configured virtual machine, with all the PHP scripts protected from reverse engineering, that can be placed behind any firewall and provide the same functionality of the Portal but in a fully private setting, where outside access is entirely under the control of the customer’s IT personnel.  Since this instance is not under the control of eXpress badging personnel, it is more exposed to tampering, even well-meaning, by the customers’ personnel, so, after deployment, eXpress badging cannot guarantee its performance and operation.  Upgrades would need to be provided via periodically-released patches, which requires an infrastructure that has not been built yet in the Portal, so, while still a possibility, it should be considered carefully and only suggested if no other configuration could fulfill an important customer’s stringent requirements and that customer has the resources to cover what should be a significantly-higher licensing cost.

Internationalization

(NOT A CURRENTLY SUPPORTED FEATURE)

The Veonics® Portal has been designed to support operation in multiple “Western” languages: languages based on the Latin alphabet (with common diacritic marks), such as Spanish, German, French, Portuguese, or Italian, and potentially languages based on other alphabets, such as Cyrillic or Russian, that are rendered left-to-right.  This clearly excludes non-alphabetic languages (such as Chinese or Japanese Kanji) and alphabetic languages rendered right-to-left (such as Arabic or Hebrew).  Partial support may apply to certain left-to-right syllabary languages, such as Japanese Katakana or Hiragana, or Cherokee, and other less common alphabets, where a common restriction will be the availability of those languages’ code pages in the supported fonts.

Implementing the internationalization framework is currently in progress, covering approximately 60% of the text in the Portal.  However, this covers the entirety of the pages that are most commonly available to most non-administrative users.  The policy has been to implement the framework in all new developments and to retrofit existing code, prioritizing the most frequently used operations and pages.  Internationalization also extends to the text in notifications, which depends on the organization within which the event triggering that notification takes place, and to the links provided for public functions, such as vID viewer and CELLfie™ page, which are tagged with the language to be used by default.  The internationalization framework also uses the default language (American English, locale code “en_US”) as a fallback whenever translation for a particular text is missing.  Finally, the internationalization framework provides a simple tool that a professional translator may use to enter the appropriate translation for every string already implemented and produces an output that can be quickly put into actual use.