OASIS Sync Technologies

OASIS has the ability to move data between a local server and a remote server(s) and database(s) through the Ingen cloud server. This technology was designed to move large amounts of data efficiently, sometimes over low bandwidth connection. This document describes the process to help identify issues and set speed expectations.

Architecture

The architecture assumes that each database operates independently and potentially without the ability to communicate with the other databases. This runs throughout the design of the system.

The architecture allows for OASIS "on prem" on the customer's server and the OASIS O4 "web browser" version of OASIS. Note: whether the database is hosted by Ingen software or the customer uses a web hosting service, like Amazon or Azure, the architecture considers these databases in the same way as “On Prem” databases.

Algorithm- How it Works

When a user creates or alters a transaction in OASIS, the signature of the transaction is recorded in a table to upload to the master database. This occurs whenever there is a save or data change in the system.

Each transaction is prioritized. This allows for transaction data to move through the architecture faster than larger lower-priority documents, such as attachments. Although the priority scheme changes periodically for better user experience, the following general priorities are used:

• transactions, such as orders, quotes, and invoices
• business entities, such as customers and manufacturers
• user information changes, such as preferences and setup information
• image files for submittals
• small attachments
• global control information
• large attachments sync after 7:00 pm local time
• price lists sync after 7:00 pm local time

Note: although the word, "transaction" is used, complex OASIS documents are often constructed of multiple transactions. A project has multiple phases – each a transaction. Each phase may have multiple quotes – each a transaction. Each attachment is treated as a transaction.

Throughout the day, each machine attached to a database will run the sync process on 5- minute intervals. After 7:00 pm, each machine will run in 60 minute intervals. 

During the sync runtime, the sync cycle begins by scanning the queue that is created when saving data in OASIS. Each transaction is sent from the local database to the master database and downloaded in priority order until the interval is up. When the time expires, the next system will start the sync process. Note: if a user saves a transaction several times during or between sync cycles, that transaction is sent one time during the next sync cycle. If another save happens after the transaction is synced, then the same transaction will be queued to sync again.

For larger groups, we recommend running a "catch up script" that runs periodically from the server to replace the workstation side sync. This process is especially useful when many of the workstations are working remotely. Note: if the server process fails, then the workstation take up the sync process automatically.

Example 1

Assume a user creates a project, provides a name, and saves. The user then adds a large attachment, updates more information, saves, and closes the project. All this happens between sync cycles. Here is what might happen:

• the project is sent to the master database
• the phase is sent to the master database
• the active quote is sent to the master database
• if time is available and the attachment is less than 10MB, then the attachment will send to the master database. Otherwise, the attachment will not send until the 7:00 pm sync.

Example 2

Consider when a payment is created, and the payment information is downloaded from the factory, pulling all invoices for the prior month into the payment. The accounting person will eventually be ready to post the payment. This process will update a number of orders and invoices– potentially hundreds of transactions. All these transactions will be queued to send to the master database during the next sync cycle. This will slow down other transactions from syncing across the architecture.

Known Issues

Low Bandwidth

Low bandwidth operations can be created in a number of ways. The most common is users operating remotely over technologies like VPN. The result is that the data must be pulled across the internet into the OASIS installation on the local PC and then sent to the OASIS cloud servers. This will cause transactions to slow down.

The solution is the run the sync process on the server. Contact customer support for help implementing this.

Attachment Priority Starvation

This issue occurs on busy days. At times, attachments will not sync quickly and may not arrive until the next typically occurs when a lot of transaction updates are generated. For groups with high volume this may be a common occurrence. However, smaller groups may see this issue when commission checks are received and a lot of payments are posted the same day. At the moment, there is no solution, as transaction priority over attachments is a requirement.