Our platforms and tech are constantly evolving

Platform Authentication

During the development of the DCM dashboards, we have started applying the 'backend for frontend' pattern to develop a gateway for the authentication and authorization tokens used towards the dashboard component. To maintain consistency across our platform, we are investigating whether we can adopt this method as the standard for all our runtime components.

What if Business Engineers could immediately use tools released the same day in Encore? We believe this is possible! Currently, however, the Blueriq Encore release cannot precede the runtime version. We are working on a plan to enable the Encore version to be ahead, allowing Business Engineers working with the Encore SaaS to directly benefit from model-independent tools and usability improvements (such as multiselect), even with a lower runtime version.

Currently, Blueriq does not offer a clear strategy for model versioning. Version numbers follow the format '0.0-branchname', meaning exports from the same branch always receive the same version, even if they differ. In practice, release branches are created, with the convention that the branch name includes a version number. Introducing release exports with mandatory versioning gives the releases an official status, which can also be traced back to a state in version control.

Having release versions gives the platform the opportunity to expand in the future (currently out of scope) with features such as:

• Defining and executing data migrations
• Starting old cases with an older model
• Increased confidence in using the correct model during session continuations (in case of failover)
• Better ability to monitor publication history

Blueriq applications are often mission-critical and play a central role in our customers' IT landscapes. Due to their strategic position in complex environments, performance issues can have a significant impact. However, identifying the root cause of these bottlenecks is not always easy. Delays often occur with connections to other systems or databases, but pinpointing the exact bottleneck can be challenging.

To improve this process, we want to add metrics to the runtime. These metrics will provide insight into the performance of Blueriq applications and their interactions with other systems. The goal is not only to identify bottlenecks faster but also to signal them in the Blueriq Cloud Platform before users experience any issues. This will enhance the reliability of these critical systems and ensure an even more stable and efficient IT environment.

Whitebox testing with Blueriq

Traditionally, Blueriq flows are often tested by applying test scenarios to the entire application where these flows are used. This means not only is the correct operation of the flow tested, but also its combination with the frontend. Additionally, smaller subflows cannot be tested individually as units but only as part of an exposed flow they belong to. We aim to solve these challenges and more with the Blueriq Testcenter.

The Blueriq Testcenter enables us to test flows as units, regardless of whether they are exposed, and without the need to test "through the frontend." This provides business engineers with better feedback at lower costs.