Skip to main content

Mercury 3.0 DB (HgDB)

Mercury 3.0 DB (HgDB)

Mercury DB is a service server (SOAP and REST) that enables the management of any objects, also referred to as cases. The engine is based on the relational SQL model, whereby data is stored in a relational database. The combination of objects and relations allows for the utilization of Mercury DB as an object database, supporting ACID transactions (atomicity, consistency, isolation, durability), as well as integration with traditional BI (business intelligence) systems for business data analysis. It facilitates interconnectivity between the domains of NoSQL databases (e.g., ElasticSearch, MongoDB) and those of relational databases (e.g., Oracle, DB2, PostgreSQL, MySQL).

Project nameAcronymDomainsStatusLatest versionCode inspection
Mercury DB (HgDB) 3.0HgDBhgdb.org
hgdb.io		ACTIVE3.0.3.2.11certificatecertificate

We developed Mercury DB (HgDB) 3.0 because we needed a way to register, search, compare, and audit data used in process applications in the enterprise.

Mercury DB (HgDB) 3.0 can be used as a data repository for process applications as a Case Database, particularly for the following products: IBM BAW IBM Business Automation Workflow and IBM BPM IBM Business Process Manager. It's a repository that's separate from the systems we already have in place. It's a centralised data repository for applications that we've created in-house (like when we want to manage any data, but don't have a dedicated system, and create a solution within the organisation, and we want the data to be safe and stored in a uniform manner for each application).

Mercury DB (HgDB) 3.0 is used in situations where the data model is changing as a result of application development. You can access the data in all the models that have been implemented at all times. You don't have to move your data to a new storage structure. The engine that identifies the types of stored objects also builds ontologies, creates new versions of them, and connects them to other ontologies. You can define alternative field names to create universal relations between data from different systems.

The Mercury DB (HgDB) 3.0 data repository stores metadata about object types as well as how they're presented on web forms and mobile apps. It's a great solution for implementing mechanisms for their automatic generation and dynamic presentation of data to the end user.

Benefits of using Mercury DB (HgDB) 3.0​

  1. Independence from the RDBMS engine manufacturer (relational database server). Mercury supports the following server implementations: MySQL, PostgreSQL, Oracle, DB2 and MS SQL.
  2. The Mercury implementation uses a uniform relational database architecture for any objects, optimized for working with large volumes of data and handling a large number of transactions.
  3. The Mercury implementation includes:
    1. Support for fast full-text search in separate noSQL structures (Apache Lucene).
    2. Use of cache memory at various levels to optimize queries to the relational database and optimize data modification actions.
    3. Access to data is possible from many systems. In the SOA architecture, implementing the "omnichannel e-commerce" strategy allows the use of Mercury for MDM (Mobile Device Management) purposes, a central repository of all data for all systems in the enterprise.
  4. Versioning of the entity definition (object type). Updating/modifying the definition of a single entity in Mercury creates a new version of it and automatically updates the connections between other model entities. It is not required to create new connections, as in the traditional SQL model.
  5. There is no fear that we will want to save/read an object with an outdated structure (a case whose structure has been changed and we have not verified it). At the same time, we have constant access to the data stored in previous versions.
  6. Advanced search methods allow for processing data from different versions of entity models and their presentation on a single list of search results.
  7. Support for external sources of dictionary data. Systems require dictionary data, which in traditional solutions are stored in tables to which data is copied from different systems and the problem of their validity appears (data synchronization between systems). The Mercury system allows for the integration of various systems and the provision of dictionary data "on-line". It supports communication with external data sources using JDBC drivers and a proprietary implementation of the HTTP/HTTPS client.
  8. We can define different data retrieval sources for Mercury server clients:
    1. As a SQL data source
    2. As a SOAP service source.
    3. As a REST service source.
    4. The Mercury system has a simple, proprietary API definition for retrieving data via the HTTP/HTTPS protocol, so if the external system does not have typical SOAP or REST API implementations, you can create your own integrations on the client system side.

Features of Mercury DB (HgDB) 3.0​

  1. Client-server architecture – The application is built in JAVA and runs on the Apache Tomcat® application server.
  2. Speed ​​and scalability – Mercury processes data multithreaded, which allows for easy vertical scaling (number of CPUs, optimal use of server power) and horizontal scaling (application server clusters).
  3. Ability to use in any application – SOAP, REST API and JAVA client available. All data operations (writing, reading, searching, versioning, ...) can be performed using the API available as SOAP, REST methods or a JAVA library, which can be used in your own applications.
  4. Universal API – Allows you to use the same set of methods regardless of the data structure. In the Mercury solution, we use object class names and sets of their attributes to identify the structures of written and read objects.
  5. Data search using Apache Lucene query syntax – Data indexing and search are based on the very effective Lucene engine, which allows for much faster access to data (needed primarily in dynamic web applications using AJAX calls, etc.
  6. Data change history registration – It is possible to register the history of changes in data. The solution allows you to track changes in data for audit purposes with a small increase in the load on the application and server. Two forms of change history are stored:
    • change snapshot – a register storing a mapping of the full object with field values ​​from before the change
    • change stream – a register of changes in values ​​for individual fields of the object. Contains data related to the name of the field, its old value and the new value
  7. Physical data structure based on the SQL database – data is stored in an SQL database (MySQL, PostgreSQL, Oracle, IBM), which allows you to use the data for reporting using external tools. Views representing defined types of objects are created in the relational database. Versioned object structure changes – Each object modification is saved as a new version of the object, which allows data to be read in the appropriate version.
  8. Possibility of object hierarchy – Mercury allows for mapping dependencies between objects and building a hierarchy of objects, which is useful for building complex business objects and mapping any data models that we use in systems.
  9. Support for OAuth 2.0 in REST services – It is possible to secure access to data via authorization mechanisms based on a token in the OAuth 2.0 standard.
  10. Protection of protected data - there are markings of individual object/case fields as protected fields. Thanks to this, they are not stored in the Lucene index.
  11. ACID transaction support (Atomicity, Consistency, Isolation, Durability) - Since the Mercury system stores object data in a relational database, during their modification operations, it uses the transaction mechanisms provided with the RDBMS engine.

Mercury Portal 2.0​

Mercury Portal 2.0

Mercury Portal 2.0 is a web application (GUI, Graphical User Interface) that allows the presentation of case data stored in the Mercury DB (HgDB) 3.0 database.

Software presentation​

Sławomir Cichy will be giving a 30-minute presentation on the Mercury Portal 2.0 software. He'll be showing how you can use the API in Mercury DB (HgDB) 3.0 to search, download and edit cases, as well as how you can create a custom look based on data stored as object metadata.

Support​

In case of problems, please contact me by e-mail at info@scisoftware.pl. In the subject of the message, please include the prefix: [HgDB].

Companies that have already used the product​

certificate

certificate

certificate

certificate

logo_wiener