. . .

Version 3.2.0

New Features

Typescript SDK (beta)

With ApiOmat 3.2.0 our newest SDK is now beta ready! The latest improvements are:

  • better handling for HTTP requests, which improves the compatibility for several frameworks and environments (react, vue, ..)

  • Handling for subclasses is now feature complete: it also works for offline tasks and offline queries

  • E-Tag & DeltaSync handling for better performance

  • embedded objects support for CRUD operations

  • Analytics-ready

  • TSDoc for all public methods

But the SDK is still in the beta phase, which means, that we are currently working on several improvements like: offline handling for embedded objects, referenced Hrefs improvements and some other minor optimizations.

Declaring the TypeScript SDK as beta is great news for our customers, because the plan is to replace the old JavaScript SDK with this SDK, which contains a lot usability improvements and modern programming language features like async/await. It can also be used in a lot modern frontend and NodeJS-backend frameworks:


The TypeScript SDK can also really easy be transpiled into ES6 and ES5 SDKs. The transpiled ES5 SDK could be a perfect replacement for all existing ApiOmat apps, which were developed with our JavaScript SDK, because it comes with a minified js file like the JS SDK and has similar syntax.

Android SQLite SDK (beta)

Android SDK Beta is now released with several bug fixes and support for working with raw SQL content. Each class represents now a table in your database. Also there's an extra method for querying data from the SQLite Database with full SQLite query capabilities.

ApiOmat Analytics Update

After updating our ApiOmat Analytics server, we've also updated our SDKs with the latest analytics features:

  • GDPR compliance handling in the SDKs and a complete new site in the analytics dashboard, which is called "Compliance Hub"

  • new widgets for the dashboard section: drill, retention, online users, ..

  • ratings and user feedback

  • filtering and views in funnels

We also added examples of the usage to our SDK documentation.

Compliance Dashboard

With 3.2.0 we introduce the new compliance manager, which could be accessed in the administration view of the dashboard. There you can ensure that your apps are developed and maintained as a GDPR compliant solution. You can download the ApiOmat Data Processing Agreement and then return it to ApiOmat. The GDPR Checklist helps developers ensure your app, website, chatbots etc. are built and maintained in a GDPR-compliant manner. You also have access to each user’s personal data. There you can fulfil the standard user requests to view their data, have it deleted as well as the objects created inside your service. You also can download all user data as a json-file, delete users and delete users with all owned data. For more information, take a look at the documentation Compliance Manager.

images/download/attachments/61479233/dataprocessingagreement.png images/download/attachments/61479233/GDPRchecklist.png

images/download/attachments/61479233/statistics.png images/download/attachments/61479233/userdata.png images/download/attachments/61479233/edit_userdata.png

Individual OpenAPI per application

With ApiOmat version 3.2.0 the Apidocs feature now runs as microservice called Explorer. The Explorer contains all defined REST end points of your ApiOmat instance like the Apidocs did before.

The Explorer also delivers a new feature to show all your application specific REST end points.
That means that already known parameters like application name, module name and model name are pre-defined and don't need to be entered by yourself, which tremendously saves time.


Furthermore you are now able to export your application specific API documentation as OpenAPI 2.0 specification and use it as standardized way to connect your application to other external services!

Visit the Explorer documentation for more details.

Graylog Integration

With an integration to the industry leading log monitoring solution Graylog, YAMBAS and other services are now capable of sending their log messages to a centralized instance.

Graylog enables the user to

  • aggregate data from multiple sources

  • initiate a search across multiple parameters and analyze, visualize, and report on the data

  • analyze data and find issues quickly with the ability to explore multiple attack vectors at once

We provide a GELF appender, which can be activated in the logging setup to fully customize, which data will be collected in Graylog and which should be kept locally.


Consul Integration

YAMBAS will now register itself at a Consul discovery service, which enables other services to find instances of ApIOmat in a clustered environment.


Also, YAMBAS will use Consul to connect to other Hazelcast instances for distributed caching.

Field value verification (regex, minimum length, maximum length)

From now on you can define your own regular expression, that an attribute's value is matched against, or to put it more simple, just define a minimum or maximum length, that the value has to meet. The verification is done during creation and update of the value and can be set via REST, native module annotations or via Dashboards class editor:


Cluster-wide atomic counter

Until now it wasn't possible for Native Module developers to implement a counter that increments by 1 with each call and always yields unique values when yambas runs in a cluster.

Now there's a new method to achieve this: YourModule.AOM.incrementAndGet(counterName, offset, optionalAppName)

This method initiates a counter with a given name and from then on increments that counter with each call by 1+offset. The counter is always module-specific, but can either be used across multiple apps (when you pass null for the optionalAppName parameter), or app-specific. The counter's uniqueness and atomicity are guaranteed by utilizing Hazelcast features, and on top of that it's backed up by MongoDB, so even when the cluster dies and you restart all nodes, the counter continues where it left off.

MongoDB Wired Tiger Support

ApiOmat now fully supports the Wired Tiger storage engine of MongoDB. WiredTiger uses document-level concurrency control for write operations; as a result, multiple clients can modify different documents of a collection at the same time.

While existing installations can keep using MMAPv1, new installations will automatically use the new storage engine which is set by default on new MongoDB installations.

Breaking changes

Breaking changes may require changes in configuration, apps, or native module code after an ApiOmat upgrade to ensure system stability.

Docker images

The name for the previous alpine-yambas image was renamed to apiomat / yambas.

Objective-C SDK

When loading data while the device is offline and no data is found in the cache, an error with the status code AOMID_NOT_FOUND_OFFLINE will be returned, instead of AOMNO_NETWORK. When using the caching strategy NETWORK_ONLY, AOMNO_NETWORK will still be returned as the cache is not used.

If you are checking for the status code AOMNO_NETWORK when loading data and the cache is used, you'll have to check for AOMID_NOT_FOUND_OFFLINE instead.


The system-wide maximum of results limitation is now set to 0/unlimited by default (was 1000 before). When querying large datasets with no limitation, database may take lots of time to collect the data. Thus, on systems where millions of entries can be queried, the yambas.limits.maxResults should be set back to a proper limit.

Remarkable changes

Remarkable changes do not affect system stability after ApiOmat upgrade, but may require changes in configuration, apps, or modules in the next development cycle.

DEB repository key

The GPG key for the Debian package has changed. Please add the newest key to bypass apt signature errors:

wget -O - https://repo-int.apiomat.com/yambas/rest/web/Key/LIVE/apiomat-archive-keyring.asc | apt-key add -

Database storage engine

The default MongoDB storage engine Wired Tiger is now fully supported in ApiOmat.

We now support Mongo's default storage engine and use it when doing a fresh install. Existing installations will keep the MMAPv1 engine, and new installations can also be re-configured to use MMAPv1 in mongod.conf.

Backend and Customer caching

We removed the nearcache configuration from our default hazelcast.xml, as the nearcache may lead to inconsistencies when reading backends or customers from the cache.

We recommend to remove the nearcache configuration from hazelcast.xml. This may result in a slight decrease in performance, but fixes unexpected Unauthorized messages due to outdated cache entries. Your map configuration should look like this example


EHCache caching was removed in favour of Hazelcast caching. Since EHCache was only used on single node deployments, no implications for productive setups are expected.

Analytics "/connect" response

Until now, even when Analytics was disabled in the config, a request to the "/connect" endpoint lead to a "200 OK" response with the message: "Nothing to do, because Analytics is either disabled or it's already connected to ApiOmat.". This also leads to the Dashboard interpreting the response as success and removing the "connect" Button in the Vendor Onboarding area.

From now on, when Analytics is disabled, it will lead to a "400 Bad Request" response with an appropriate message. Also, in case of an actual success, a "200 OK" response is sent, without any message.

All changes in the current and previous versions can be found at the root page.

All deprecations and their removal date can be found at Deprecations and Migration.






com.atlassian.sal.api.net.ResponseException: org.apache.http.conn.ConnectTimeoutException: Connect to jira.apiomat.com:443 [jira.apiomat.com/] failed: connect timed out Diese Vorgänge in Jira anzeigen