There are a few low-level changes that won’t make it to the release notes, but make a difference for users. For example, we optimized the data caching mechanism. Instead of being based on the number of datasets, the data caches are now based on the size of these datasets. This typically means lower latency as more datasets tend to be cached within the same memory space. This is a feature we initially used only with WITSML wells, and that we have extended to other connectors and data types.

The IVAAP data model was created after researching the commonalities between the industry data models. However, when we built it, we kept in mind that each data store carries its own set of information, information that is useful for users to consume. This is why we made “properties” a part of the data model itself. From an IVAAP SDK point of view. “Properties” is a set of name-value pairs that you can associate with specific entities within the IVAAP Data Model.

One of the productivity features of the IVAAP Data Backend SDK is that the services developed with this SDK are container agnostic. Practically, it means that a REST service developed on your PC using your favorite IDE and deployed locally to Apache Tomcat will run without changes on IVAAP’s Play cluster. While the Data Backend SDK is traditionally used to serve data, it is also a good candidate when it comes to developing non-data related services. For example, as part of IVAAP 2.8, we worked on a “gridding” service. In a nutshell, this service computes a grid surface based upon the positions of a top across the well of a project. When we tested this service, we didn’t deploy it to IVAAP’s cluster, it was deployed as a standalone application, as a servlet, on a virtual machine (VM).

One of the unique capabilities of IVAAP is that it works with the cloud infrastructure of multiple vendors. Whether your SEGY file is posted on Microsoft Azure Blob Storage, Amazon S3 or Google Cloud Storage, IVAAP will be capable of visualizing it.

As the use cases of IVAAP grow, the implementation of the data backend evolves. Past releases of IVAAP have been focused on providing data portals to our customers. Since then, a new use case has appeared where IVAAP is used to validate the injection of data in the cloud. Both use cases have a lot in common, but they differ in the way errors should be handled.