In June 2026, the Medical Devices Template Team released version 1.3.0. This is a minor release, but it brings a meaningful set of enhancements to two of the areas that matter most in a regulated manufacturing environment — electronic Device History Record (eDHR) validation and Continuous Flows. In addition, a new Assemble mode has been introduced and several smaller enhancements were also delivered, addressing recurring requests from implementation projects.

In this post, we’ll walk through the new features and enhancements shipped in 1.3.0, with a closer look at the most impactful ones: eDHR Validation and Sign-Off, Automatic Explicit Add, and a handful of Continuous Flows improvements.

Summary of New Features and Enhancements

The table below summarizes what’s new in Medical Devices Template 1.3.0.

The release also includes a number of bug fixes, mostly related to Continuous Flows edge cases (tail termination, merge logic, rank consistency on move-next, and rework counters).

You can find the full list of work items in this minor release in the Release Notes.

eDHR Validation and Sign-Off

Anyone that has worked on a Medical Devices implementation project knows that generating and signing off a Material/Device History Record is a core, non-negotiable requirement. Before this feature, either reports would need to be manually generated and attached as evidence in MES or similar automatic behavior would need to be designed and implemented on a per-project basis.

The new eDHR Validation and Sign-Off feature turns this into a template configuration-driven capability. In short, it lets you:

• Associate a Material (or a group of Materials) to a Validation Protocol, automatically, as it reaches a specific Step.
• Generate a Stimulsoft-based report to PDF and attach it to that Protocol Instance, also automatically triggered by the flow.

The association and the report generation don’t have to happen at the same Step. A very common pattern is to associate Materials with a Protocol right at the start of the flow, and only generate/attach the eDHR report at the very end, once all manufacturing data is available. This is all configured in the MedDevMaterialProtocolContext Smart Table (see screenshot above), where you define, per Step:

• Operation — either AssociateMaterial (just links the Material to the Protocol Instance) or AttachDocument (generates the report and attaches it).
• GroupingProperty (or a custom GroupingRule) — how Materials are grouped into the same Protocol Instance: by Name, Production Order, or Manufacturer Lot Number. The latter is particularly relevant for Continuous Flows scenarios, where validation typically happens at lot level rather than per individual Material.
• Report and Report Parameters — which Stimulsoft report to render, and any filter parameters, which can even reference placeholder expressions such as {{Material.Name}} or {{Material.ManufacturerLotNumber}} to be resolved dynamically at runtime.

{
  "MaterialName": "{{Material.Name}}",
  "LotNumber": "{{Material.ManufacturerLotNumber}}",
  "ProductName": "{{Material.Product.Name}}"
}

Under the hood, report generation is asynchronous: an Integration Entry of type GenerateAndAttachReport is created, and a DEE Rule takes care of rendering the report and attaching the resulting PDF to the Protocol Instance.

A couple of details worth highlighting:

• The MaterialSelectionRule column lets you filter which Materials in a group actually trigger report generation — for example, only the Tail material in a Continuous Flow lot, using the out-of-the-box MedDevCheckSourceMaterialIsTailMaterial rule, avoiding unnecessary report generations for every Material in the group. Since this is a Rule, you can also implement your own custom logic if needed.
• The Override flag controls whether a newly generated report replaces an existing attachment for the same report path, or whether generation is simply skipped if one already exists.
• If needed, ValidateReplication can be enabled to ensure the report is only generated once the material’s last Service History ID (SHID) has been replicated to the ODS — useful when the report relies on OData/ODS-backed data.

To conclude this topic, the next version will include a on-demand report regeneration feature, directly from the Protocol Instance page. If a report needs to be reissued — say, after a data correction — an authorized user will be able to trigger a new generation for any previously attached report, without needing to reprocess the entire flow.

Automatic Explicit Add

An operator manually picking source Materials for an manual Assemble operation is repetitive, error-prone, and adds unnecessary time to an operation that, in most cases, follows a predictable FIFO pattern from a set of consumable feeders. While automatic consumption could be used in most cases, for Explicit Add scenarios the operator still needs to manually select the source Materials, which is not ideal.

Automatic Explicit Add is a new feature that combines the benefits of semi-automatic consumption with the flexibility of manual selection. When a Material sits at a Step with an Explicit Add BOM, the operator can trigger a new Automatic Explicit Add wizard instead of the standard Assemble flow. The system calculates the consumption plan in the backend, resolving, for each BOM Product, which Materials from the Resource’s Consumable Feeds should be consumed — following FIFO order — until the required quantity is fulfilled. In a real scenario, this means the operator can attach the consumable materials to the feeders during Resource Setup; the system will then automatically select the right batches for consumption, without the operator needing to manually pick them.

The wizard exposes a single new flag: Skip Confirmation.

• With Confirmation (OFF) — the system calculates the plan and presents it in the standard BOM confirmation step, so the operator can review the selected source Materials and quantities before confirming.
• Without Confirmation (ON) — the confirmation step is skipped entirely, and the standard AssembleMaterial service is called directly with the computed plan.

The following list summarizes the backend steps that happen when an operator opens the Automatic Explicit Add wizard:

1. Resolve Material + processing Resource
2. Load current BOM, determine eligible BOM Products
3. Calculate required quantity per BOM Product
4. Resolve Consumable Feeds from the Resource
5. Read queued Materials in the Consumable Feeds
6. Apply FIFO consumption planning
7. Confirm (or auto-call AssembleMaterial)

One consumption detail worth calling out: if the first available Material in a feed doesn’t have enough quantity to fulfill a BOM Product’s requirement, the system doesn’t stop there — it continues consuming subsequent Materials of the same Product, in FIFO order, until the quantity is met (i.e., Multi-Material Consumption). And if, at any point, the available quantity across the feed is simply not enough, the operation is blocked entirely — regardless of the confirmation mode — with a clear message indicating which BOM Product(s) are short.

ℹ️ Skip Confirmation default value
The default behavior of the Skip Confirmation flag can be set per project through the standard GUIElementDefaultValue table (Context = MedDev.AutomaticExplicitAdd, Element = ShowConfirmation).

Other Enhancements

Alongside the two headline features, 1.3.0 delivers more targeted improvements, mostly around Continuous Flows and Data Collection handling.

Rework / Temporary Off-Flow in Continuous Flows

Continuous Flows already supported automatic re-evaluation of Material ranks (Head, Middle, Tail) as chunks move through the flow. In 1.3.0, this re-evaluation logic is extended to cover Materials that temporarily leave the main flow through Rework or a Temporary Off-Flow path.

While a Material is out of the main flow, it’s assigned a dedicated InRework rank. When it returns, MES determines its new rank — Head, Middle, or Tail — based on its position relative to the remaining Materials still in the flow, following the same logic already used for regular flow progression. This means Continuous Flow processes that rely on Rework or Off-Flow paths no longer need custom logic to keep material ranks consistent after a return. The following diagram shows the implemented rank re-evaluation logic for a Continuous Flow lot returning from a Rework path.

Label Reconciliation with Splits & Merges

The Label Reconciliation feature — which tracks printed labels through verification and final reconciliation — now works properly with Continuous Flow’s Splits & Merges. Previously, verification counts (good, scrapped, first/last label checks) were only tracked at the individual Material level, which didn’t map well to a Continuous Flow scenario where a lot is split into multiple parallel chunks.

With this enhancement, printed label counts are recorded and reconciled against the Main Material of the Continuous Flow group, regardless of which specific chunk triggered the print or the verification step. When a Protocol Instance is opened for label verification (manually, or automatically due to a violation), all active Materials sharing the same Manufacturer Lot Number are automatically associated with it — keeping the full lot in sync for sign-off purposes.

Skip Duplicate Protocol Instance Creation on DC Limit Set Violation

A smaller, but very practical fix for a common pain point: when a Data Collection Limit Set is violated repeatedly for the same Material group, the system used to open a new Protocol Instance on every violation. In regulated environments this quickly becomes noisy — multiple open Protocol Instances for what is essentially the same underlying non-compliance.

1.3.0 introduces the MedDevIgnoreInstanceCreationIfAlreadyAssigned Protocol attribute. When enabled, if the violating Material (or, for Continuous Flows, its group) is already associated with an open instance of the same Protocol, the system suppresses the automatic creation of a new Protocol Instance and simply keeps the violation tied to the existing one.

Wrap Up

Version 1.3.0 continues the trend we’ve seen in recent Medical Devices Template releases: closing the gap between generic MES capabilities and the very specific compliance and traceability needs of medical device manufacturing, particularly around Continuous Flows and eDHR/Report Validation.

Feel free to reach out to the Medical Template Team with questions or feedback on any of these features!

Public Documentation

• Feature Guide — eDHR Validation and Sign-off
• Feature Guide — Automatic Explicit Add
• Feature Guide — Continuous Flows (updated)
• Feature Guide — Label Reconciliation (updated)
• Information Center — Release Notes + Sample Master Data

Author

Hi! My name is Ricardo Cunha. ✌️

I joined Critical Manufacturing back in 2013. I started my journey as a Software Engineer, progressed to Tech Lead, and currently serve as Engineering Lead in the Medical/Life Sciences segment in Solutions Delivery area, as well as Team Lead for the Medical/Life Sciences template team.

You can check me on LinkedIn

In the previous post, we explored how AI can assist in the development process by generating code snippets and providing suggestions. In this second part, we will take it a step further by implementing a real-life feature using Spec Driven Development with the help of AI tooling.

Introduction

While the first experiment was promising, it was mainly focused and limited to generating code snippets and unit tests. I wanted to see how AI could assist in a more comprehensive development process, using real-life examples. For this experiment, I chose two new enhancements planned for the Medical Devices Template solution. For the first one, which was the simplest, I used the traditional approach of just writing the prompt I thought would be best for the task. For the second one, which was more complex, I used a more structured approach, following the Spec Driven Development methodology, which I will explain in more detail later.

ℹ️ Medical Devices Template
For more information about the Medical Devices Template and its features, please check Critical Manufacturing’s Documentation Portal: User Guide and Tutorials.

Regarding tooling, I used GitHub Copilot CLI with an enterprise account. This tool allows you to interact with GitHub Copilot directly from the command line, making it easier to integrate AI assistance into your development workflow. The look and feel and commands are very similar to the ones you can find on Claude Code.

Enhancement 1: Fixing a Bug in the Installation

The first enhancement was to fix a bug in the installation process of the Medical Devices Template. In the current development cycle (not yet released), we are extending the Continuous Flows feature to support materials sent to Rework, by supporting a new In Rework rank. The issue was that the installation process rule was not properly handling scenarios where a previous version of the MedDev Template was already installed. In those cases, the installation process was not creating the In Rework rank, resulting in an inconsistent state of the system.

Since the fix was relatively simple, I decided to use the traditional approach of just writing a prompt that I thought would be best for the task. I provided the AI with the necessary context (including the actual file) about the issue and asked it to generate the code to fix the bug.

ℹ️ Accessing the framework
You can see on the prompt I am referring to the location of the CM Framework source code. I wanted to ensure that the AI had access to the relevant code, if required, and could understand the context of the issue.

The log generated by Copilot CLI is shown below. As you can see, the AI was able to understand the context.

The AI generated the code to fix the bug, which I then reviewed and tested. The generated code was correct and fixed the issue as expected. This was a good indication that AI can assist in fixing bugs and generating code for simple tasks, even without a more structured and detailed approach.

Enhancement 2: Refactoring configuration within an existing feature

The second enhancement required a deeper refactoring of the Continuous Flows feature. If you check closely the documentation you can see that there are several feature flags that enable Continuous Flows and related functionality, such as re-evaluating ranks automatically or creating future merge actions at a later step in the flow. The goal was to implement an additional level of configuration, allowing the same feature flags to be enabled by context and not globally, if required. This allows greater flexibility and allows the activation of these features only for specific contexts. The following diagram shows the logic we wanted to achieve at the end.

While functionally the change in itself is not very complex, it requires changes on several layers:

➡️ Renaming existing config entries to indicate they are now global settings

➡️ Migrating values of old configuration entries to the new ones, if applicable

➡️ Creating a new context smart table to store context-specific Continuous Flows settings

➡️ Refactor Business logic code (several DEEs) to implement the new logic described above, while ensuring that the existing logic is not broken and that the new logic is properly integrated.

➡️ Update existing unit tests and create new ones to cover the new logic.

While I could have just written a prompt describing the tasks, I wanted to try a more structured approach, following the Spec Driven Development (SDD) methodology. SDD is a methodology that focuses on writing detailed specifications for the desired behavior of a feature before implementing it. Teams write executable or reviewable specs that define as much as possible what the software should do. The spec documents are not static documents, but rather living documents that can be executed or reviewed to ensure that the implementation meets the specified behavior.

For this use case, I created a spec document with the following sections:

1. Why and What: Short descriptions of why and what we are changing from a high-level standpoint.
2. Constraints: Any musts and must nots that should be considered during the implementation. For example, if this was a feature written from scratch with external libraries dependencies, one could specify what library must or must not be used.
3. Tasks: A detailed list of tasks that should be implemented to achieve the final result. In this case, each task corresponded to one of the layers mentioned above. Initially I had a final task regarding integration tests, but decided to remove it since it is better practice to have another developer implement them. For each task, I provided a detailed description of what should be done, and in some cases, guided the agent to which files should be modified.
4. Validation: After the agent finished its tasks, it should perform some validations, mainly that the project builds successfully and that all unit tests pass.

Initial spec implementation

The following image shows a snippet of the specification file, showing the first part of the document.

The prompt in this case was very simple: just reference the spec document and ask the agent for any clarification that it thinks is necessary.

Although I expected the agent to finish each task (reasoning and coding) before moving to the next one, it actually spent the first minutes thinking and reasoning about the entire list of tasks, and only then started implementing the first one. While the code was being generated, reviewed and accepted, I noticed a couple of issues:

• The agent was able to abstract the feature “enabling” logic to a common method that was then used across the code, which was good. However, in one particular case, it removed the previous feature enable check but it did not replace it with the new common method.
• In one case, it did not add the expected using namespace statements in the file. Note that I fixed this manually while the agent was still working on the other tasks, but I believe in the final validation step, the agent would be able to identify that the code does not compile and fix the issue.

Changing the spec

The first version of the spec was implemented successfully, however two change requests were now required:

1. After clarifying with the Product Manager, it was required to add the ProductionOrder as key in the new context smart table.
2. The original spec did not include any details about updating documentation, both technical and functional (user guide).

For the first one, the change in the spec is straight forward. Just updating the smart table specification by adding the new ProductionOrder key and asking in the prompt for the necessary code changes to support the new key.

In this particular case, I ran the prompt using Plan mode. The agent was able to generate an execution plan to be reviewed, changed (if necessary) and accepted. In this case, the change was relatively simple, so the plan was straightforward and was accepted without changes.

ℹ️ Agent vs Plan modes
It’s good to run the prompt in Plan mode for more complex changes. That was not the case here, but the model could return a plan that needs to be reviewed and adjusted before execution, which adds an extra layer of control to the process.

For the documentation, the spec was changed to add two new tasks, one for technical documentation and another for the user guide. After reviewing, a small change on the user guide was performed, in relation to the order of the sections, but overall the generated documentation was good and only required minor adjustments.

Conclusions

This experiment showed that AI can be a valuable partner in the development process, not only for generating code snippets but also for implementing more comprehensive features. The spec-driven approach provided a structured way to guide the AI through the implementation process. While the AI was able to understand the context and generate code for the tasks, it still required some level of supervision and review to ensure that the implementation was correct and met the specified requirements. Nevertheless, while the SDD-implemented feature would probably take a couple of days to finish in the “old days”, it was implemented in slightly over half a day, which is a good indication given this was a first experiment.

For future experiments, we could explore ways to improve these spec documents and how they would behave on more complex features or even features developed from scratch. We can also improve our prompts and see how the model behaves, for example being explicit on completely finishing one task before moving to the next one, or asking for a more detailed execution plan before starting the implementation.

Always remember to review and understand what the AI generates.

Resources

You can download the final version of the spec document here.

Author

Hi! My name is Ricardo Cunha. ✌️

I joined Critical Manufacturing back in 2013. I started my journey as a Software Engineer, progressed to Tech Lead, and currently serve as Engineering Lead in the Medical/Life Sciences segment in Solutions Delivery area, as well as Team Lead for the Medical/Life Sciences template team.

You can check me on LinkedIn

“Another JavaScript framework? God, why did I choose this field?”

If you have been working with software for a significant number of years, you probably have heard or even asked yourself the exact same question. But for about two years now, all the talk has been related to Large Language Models (LLM). And if we thought new JavaScript frameworks were popping out like mushrooms, then compared to the latest updates in the AI/LLM world, it was no big deal after all…

Introduction

For decades, the developer experience has been about mastering tools: IDEs, debuggers, compilers, version control. You learned the tool, and the tool did exactly what you told it to. AI and LLMs are changing the contract. The new generation of tools doesn’t just execute instructions — they understand them.

Although models like Claude, GPT or Gemini bring the ability to reason over natural language, explain complex systems and generate meaningful content, the truth is LLMs have real limitations: these models have been trained up to a certain point in time, meaning they have a fixed knowledge cut-off. They have no knowledge of current events or inherent access to your codebase. The models themselves have no idea of what the current weather is in Porto or the world’s current geopolitical… situation.

But over the last couple of years, the industry has converged on a set of patterns and protocols that let you extend what an LLM knows and can do. It’s no longer a smart auto-complete / summarization tool - it’s an active collaborator in your workflow.

Extending LLMs

So what are these patterns and tools that can be used to extend the context provided to LLMs? The following image provides a summary of the different layers that compose the extensibility ecosystem of an LLM.

At the foundation layer, you have the LLM itself — a transformer model with powerful reasoning but bounded knowledge.

At the context layer, you shape what the model knows and how to behave. This includes:

• Prompt Engineering: Crafting prompts in a way that guides the LLM to produce the desired output.
• Skills: Pre-built/packaged functionalities that can be invoked by the LLM to perform specific tasks. They are not bounded only by instructions, but can even execute scripts/code.
• Retrieval Augmented Generation (RAG): A technique that allows LLMs to access external knowledge bases or documents to provide more accurate responses.

At the connectivity layer, you have tools that enable the LLM to interact with external systems and APIs. Here the buzz has been around Model Context Protocols (MCP), a standardized way for LLMs to access and interact with external data sources. MCPs allow LLMs to fetch real-time data, query databases, or even interact with other APIs, effectively bridging the gap between the model’s static knowledge and the dynamic world.

Finally, at the orchestration layer, where agents and workflows come into play. Agents are autonomous entities that can perform tasks on behalf of the user, while workflows allow you to define complex sequences of actions that can be executed by the LLM and its connected tools.

Developer Experience in Critical Manufacturing

Now the question becomes: how can we leverage these tools to enhance the developer experience in Critical Manufacturing?

As a first experience, I have explored three different use cases:

➡️ Boilerplate code generation

➡️ Unit tests generation

➡️ Code Reviews

Boilerplate Code Generation

Whenever a new DEE action or custom service needs to be created, the usual approach is to copy code from existing ones and adapt it (change action/service names, change input & output classes, etc.). Especially for new services, this is boring and slightly time-consuming. Another challenge is ensuring that the LLM has the necessary context to generate code that is consistent with the existing codebase. How can we do that?

For this, a new skill was created that instructs the LLM on what to do when asked to generate boilerplate code. The skill provides the LLM with a template of the code structure for each scenario (DEE action or custom service), along with guidelines on how to fill in the blanks based on the provided specifications. The skill also includes examples of well-structured code snippets to serve as references for the LLM.

ℹ️ How to create new skills?
Skills can be created in your repository, by creating a new folder and a SKILL.md file with the instructions. If you’re using Visual Studio Code, you can check in the Settings the available Agent Skills Locations, or add new ones.

As mentioned before, the instructions are specified in a markdown file that is passed as context to the model. You can find an example of the instructions provided in the Boilerplate Code Skill created for this use case.

Here is the code generated for a potential new DEE action. VS Code Chat was able to understand with just natural language what I wanted to achieve ("create a new DEE Action (…)") and automatically used the skill to get the instructions.

ℹ️ Code generation for other layers
During this experience, a skill focused on GUI components (widgets, wizards, etc.) was created. However, there are already some commands to generate this boilerplate so the advantage of using an LLM for this is not as visible. For GUI components, the commands are usually faster.

Unit Tests Generation

Unit tests are a critical part of software development, but they can be time-consuming to write. By leveraging LLMs, we can automate the generation of unit tests based on the existing codebase and the specifications provided by the developer. In this use case, the approach followed was different. I selected an existing project that had no unit tests and no skill or agent was created.

1️⃣ A set of unit tests were manually created for a sample DEE action, covering the most common scenarios and edge cases.

2️⃣ The generated unit tests were then used as a reference for the LLM to generate additional unit tests for other DEE actions in the same project - this was explicit in the prompt.

There were some observations on the subsequent attempts to generate unit tests with the LLM:

• The LLM was able to generate unit tests that were consistent with the style and structure of the manually created ones and it was able to generate tests covering approximately 100% of DEE code.
• Without being explicit in the prompt, the LLM typically generated different unit test methods for each test combination instead of trying to reuse and parameterize them (i.e, xUnit’s Facts and Theories).
• When generating tests for a new DEE that had different Input “types” (i.e., an orchestration Input/Output class), the LLM struggled to understand how to generate the unit tests. Eventually, I cancelled the execution.

The last point touches on an important aspect of this whole experience: the LLM’s ability to understand the context of the entire codebase. In this case, the LLM had no prior knowledge of the CM internal framework’s patterns and structures, which made it difficult for it to generate accurate unit tests for new scenarios. Nevertheless, in most cases the LLM was able to assist in the generation of unit tests. In a particular scenario, with a DEE whose structure was similar to a previous one, it took less than 5 minutes to generate, review and commit the code to the repository.

⚠️ A note on code generation
Always review and adapt the generated code, if necessary! Keep vibe coding for personal projects and prototypes, not for enterprise-grade production code. The ones that need to maintain the codebase in just a couple of years will really appreciate it…

Code Reviews

I was quite happy with the previous experiences but I wanted to go even further. What about code reviews? Can LLMs be used to assist in code reviews and provide feedback on code quality, potential bugs, or adherence to coding standards?

For this use case, instead of a skill, an agent was created that could analyze code changes from a particular feature branch. I focused the code review on C#/.NET projects in the repository. The agent’s workflow in itself was simple:

• Calculate the diff of the feature branch with the main/development branch.
• For each changed file, review the code for naming conventions, potential bugs, performance improvements, etc.
• Provide a summary of the review, by categorizing each finding with a severity level (e.g., 🔴 CRITICAL, 🟠 HIGH, 🟡MEDIUM, etc. )

While C#/.NET best practices are quite well-known and documented, the challenge was to provide the LLM with enough context to understand the specific coding standards and patterns used in the CM codebase. For this, the instructions for the agent also included examples of typical issues found in code reviews: loading large object graphs into memory (the levelsToLoad issue 😖), loading inside loops, etc.

For a first approach, I was quite happy with the results. I tested with a real feature branch and the agent was able to identify a critical bug in the logic, which would lead to the feature being completely broken.

However, a couple of observations were made:

1. The generated report, although very complete, was too verbose and not easy to read.
2. The agent definition .md file already had more than 500 lines.

The first point is something that can always be improved by providing better instructions to the agent on how to summarize the findings and how to present them in a more concise way. For the second one, I decided to test a multiple sub-agent approach: one agent acted as the orchestrator, while multiple child agents were responsible for reviewing specific aspects of the code.

Using this approach, we can select the orchestrator agent in the context window and just ask it to review the code. The orchestrator will then delegate the review to the different sub-agents and aggregate the results in a final report.

Nevertheless, there were some challenges with this approach, especially regarding the conflicts of some findings. The runtime sub-agent, responsible for looking into possible null reference exceptions, might point to potential issues which are in conflict with some assumptions made by the CM framework sub-agent. For example, the ServiceProvider must always be an Input in the DEE Actions. The runtime sub-agent might point to potential null reference exceptions related to the ServiceProvider, while the CM framework sub-agent might not consider it as an issue since it’s a known pattern in the codebase. This led to some confusion, and a new instruction was added to the orchestrator agent to prioritize the findings of the CM framework sub-agent.

Here is an example of the generated report for a particular feature branch:

The Critical finding was actually part of the change request, so the fact that the model does not have the full context makes it appear as a critical issue when it is not. Be on the look out for false positives. 👀

Conclusion

The goal of this experiment was to play around with the different tools and patterns available to extend LLMs and see how they can be applied to enhance the developer experience in Critical Manufacturing. The results showed some potential benefits in terms of productivity and code quality, but also highlighted some challenges that would need to be addressed. In addition, another question is how to integrate these tools into the existing development workflow. Can code reviews be fully automated and part of the pull request pipelines? Can unit test generation be triggered by specific commits or branches? These are questions that we will need to explore in the future.

Resources

You can download the (current) final version of the skills and agents used in this blog post here.

Author

Hi! My name is Ricardo Cunha. ✌️

I joined Critical Manufacturing back in 2013. I started my journey as a Software Engineer, progressed to Tech Lead, and currently serve as Engineering Lead in the Medical/Life Sciences segment in Solutions Delivery area, as well as Team Lead for the Medical/Life Sciences template team.

You can check me on LinkedIn

Introduction to Low Code integrations

In the original post from this series, we looked at the core of our built-in enterprise integration framework, with special focus on the definition of Integration Entries and the high-level explanation on how the integration pipeline operates. The post’s content was based on perhaps the most frequent system integration example we observe in CM MES implementations: using the GenericIntegrationHandler integration package and handle the integration logic using DEE Actions, each responsible for handling specific message types. Since DEE actions are, after all, a collection of C#/.NET code using the CM MES internal framework, they fall in the category of traditional software development. On specific use cases, traditional development might bring some drawbacks:

➡️ Time: Traditional development focuses on manual coding, which is a time-consuming task - even in the age of AI-based code generation tools. Furthermore, time-consuming tasks do not end with just manual coding, because other important phases of software development are closely impacted: code reviews, deployment actions (e.g., new package deployment when an integration is changed or a bug is fixed), etc.

➡️ Technical Knowledge/Skills: It goes without saying that traditional development requires specific expertise in software engineering. In practice, this expertise might result in the need to understand multiple programming languages and respective frameworks and/or libraries. As a consequence, not all parties of an implementation project will be able to actively contribute to these integrations, either by creating new ones from scratch or changing/fixing others.

In certain integration use cases, a low code integration platform could be a viable solution. Low code development can be described as an alternative approach on building software: an approach where little code is required. Instead, the business process is built using visual tools, such as drag-and-drop, pre-built widgets with simple manual coding, only when required. In essence, the user builds a workflow, connecting the different widgets and deciding how the information flows until reaching the end of the execution.

Low code platforms can bring the following advantages when building new integrations:

🚀 Implementation Speed: By offloading implementation logic to pre-built components, the user’s main task becomes building a visual workflow, connecting and configuring the required components so that the business value is reached at the end of the workflow’s execution.

📚 Skills: Since the implementation details are part of the pre-built components, the user would only need to develop code, under certain conditions (e.g., if there is no provided component that fulfills a particular task). For specific simple scenarios, a workflow could be implemented without the need for extra coding. Consequently, users with different backgrounds and roles could contribute for certain interfaces.

🧪 Prototyping/PoC: Considering the two points above, it’s easier to setup a prototype or a proof of concept for new integrations without the need to step into the traditional software development and deployment cycle.

🔁 Reusability: The components that are available to build the low code workflows are reusable, thus avoiding frequent programming issues such as not following the DRY (Don’t Repeat Yourself) principle or creating technical debt.

⚠️ Choose the right tool for the job
The goal of this post is to describe a different approach for implementing integrations in CM MES, not to determine that “A” is better than “B” or vice-versa. In fact, low code solutions can also create new challenges in other areas such as change management and governance, especially in highly regulated segments, such as medical devices. Traditional or low code development are not mutually exclusive and can be used in conjuntion.

In the CM MES ecosystem, there are more examples of low code solutions which you might already be aware of. Connect IoT uses low code workflows to easily setup and build integration scenarios. More recently, a new feature called Business Workflows was implemented and made available, where users can build simple workflows to react to certain events and execute CM MES operations according to their functional requirements.

In the next section, an example will be provided on how to configure, execute and monitor low code workflows in the context of enterprise integrations. At the end we’ll take a closer look at the different technical components in place and how the solution is designed from a high-level standpoint.

Demo: Importing a Production Order

For this demonstration, I wanted to show an example that would be simple to understand, but at the same time would resonate to those actively working in implementation projects with ERP integrations. Taking this into account, in this example we will simulate the creation of a new production order (in this case represented by a Material instance), by receiving this JSON payload:

Configuration

First, we need to register our event/payload as an IoTEventDefinition. Create a new instance for scope Enterprise Integration, and enter the properties mentioned above.

💡 At the event definition creation wizard, instead of entering each property individually, you have the option to Import a JSON file or template. The wizard will parse the content and generate the properties automatically. Nevertheless, ensure that the properties are created with the expected data type.

Now that the event is registered, an AutomationController must be created. Create a new one for scope Enterprise Integration and choose the IoTEventDefinition created above. In this controller, we will define the workflow that will be triggered when the integration entry is set to be processed.

In the workflow above, we have setup the following tasks:

1. Job Start
   • Initial task that just outputs the list of properties defined in the IoTEventDefinition.
2. Load Facility
   • The task receives as input the PlantCode from the event definition.
   • As a code task, it is running a query to retrieve the Facility whose custom attribute matches the PlantCode, and returning it as the output.
3. Load Product
   • Similar to Load Facility, but just loads a Product whose name matches the input PartNumber.
4. Create Material Object
   • With the original event properties and the result of the previous tasks, this task builds a Material object and returns it as the output.

5. Call CreateObject
   • This task will call the CreateObject API, to create the input Material object.

After the AutomationController is approved and set effective, the only thing missing in the configuration should be more familiar. In the IntegrationHandlerResolution smart table, the IoTEventDefinition created above should be defined in the respective column instead of a DEE Action.

Execution

After the configuration is in place, we can test the execution by creating a new IntegrationEntry with the respective MessageType and the expected JSON payload. For integration entries processed using this mechanism, additional information can be reviewed, since an AutomationJob is created. Execution metadata such as the duration, creation time and completed date are available in the entry’s details page.

Technical Overview

We’ve seen from a functional standpoint what needs to be configured to set up enterprise integration workflows using event definitions. But how does this technically work? The following diagram explains from a high-level perspective the relationship between the different components in this processing pipeline.

The initial part of the process is similar to what we have seen before; it’s not relevant if an integration entry message type is configured to be processed by the traditional implementation route (e.g., DEE Action) or by low code workflows (IoT Event Definition). The IntegrationEntry is created either by external applications (inbound) or by CM MES itself (outbound). The previously described integration orchestrator will pull the respective integration entry to be processed and, if the configuration in the IntegrationHandlerResolution smart table determines that the handler type is GenericIntegrationHandler and the IoTEventDefinition column is not empty, then it will trigger the pipeline to process that message.

The integration handler will send a message to the Apache Kafka broker, containing not only the original message’s payload but additional metadata, including the EventTime, IPAddress and other event properties. In the Kafka cluster, there will be one topic for each registered IoTEventDefinition. For example, during the demo described above, a new topic was created in the environment’s Kafka cluster with the format <EnvironmentName>_enterpriseintegration_customimportorder_raw, being CustomImportOrder the name of the IoTEventDefinition. One could even monitor and read the messages written to the respective topic. For example, in a CM MES environment where Kafka is hosted as a pod inside our deployment stack, we can open a terminal inside the running pod and use the kafka-console-consumer CLI tool to read the incoming messages.

In this case the CM MES Host component is the producer, while the Connect IoT Manager will be the consumer of the messages.

⚠️ Connect IoT Manager
By default, a Connect IoT Manager deployment will be created and started when the application is installed. This manager will also contain a default Automation Controller Worker, that has been configured to handle these integration cases.

After the Connect IoT Manager consumes the message, it will use the Host’s API to create an AutomationJob. The Host will create the object in the database but also send another message to the RabbitMQ instance, which again will be consumed by the Connect IoT Manager’s internal controller. This will trigger the execution of the job, instantiating the respective AutomationController. Depending on the tasks in the workflow, the IoT process will call CM MES APIs in the Host component, finalizing the execution by completing the AutomationJob.

⚠️ Execute Service Call tasks
The workflow execution is not an atomic operation: in a scenario of multiple service call tasks, these are not executed under the same transaction. In the example above, only the CreateObject service call changes state in CM MES, but in the case of multiple state-changing service calls, one is required to handle potential inconsistencies when one service call succeeds but the following in the workflow does not. Consider those potential issues when designing your workflows.

Summary

In this post, we took a look at an alternative, relatively new way to integrate with external systems, focused on visual widgets/components that can be orchestrated via drag-and-drop operations to build a comprehensive integration workflow, with minimal additional coding. As previously stated, this is an alternative way that can be used together with the traditional development approach, since they are not mutually exclusive. For simple integration scenarios, low code integration can be a valid alternative and even provide some advantages, such as the speed of implementation.

To conclude this post, it is worth mentioning that there are already plans to provide, in advance, integration scenarios for common use cases, such as importing a production order from SAP.

For follow-up questions or other topics that you’d like to be in this blog regarding integrations, please feel free to reach me!

Author

Hi! My name is Ricardo Cunha. ✌️

I joined Critical Manufacturing back in 2013. I started my journey as a Software Engineer, progressed to Tech Lead, and currently serve as a Technical Architect in the Solutions Delivery area, providing technical guidance for CM MES deployments.

You can check me on LinkedIn

In today’s dynamic technological landscape, the need to integrate diverse software systems using appropriate communication protocols is increasingly common for delivering comprehensive solutions to complex requirements. While traditional client-server integration has largely relied on the synchronous Request-Response architecture (Synchronous APIs), non-blocking, fire and forget Asynchronous APIs have gained significant traction in recent years, driven by the growing adoption of microservices architecture and its associated server-to-server communication demands.

In essence, a Synchronous model requires the caller to wait for the request to be fully processed before receiving a response. Conversely, in an Asynchronous model, the request is stored externally (e.g., database, message queue) for background processing, and the API immediately acknowledges receipt to the caller. In scenarios where immediate process results are not critical, this API architecture offers several key advantages:

➡️ Long-running tasks: For operations expected to take more than a few seconds (e.g., image/video processing), it’s a best practice to provide immediate feedback to the caller while processing the request in the background.

➡️ Scalability: By offloading processing to background workers, the API can handle a higher volume of incoming requests without being blocked by the processing time of each operation.

➡️ Service decoupling: Request-response models can create tighter dependencies between services. Asynchronous models reduce this coupling by allowing services to communicate indirectly. For instance, Service A can send a message to a storage mechanism, and a background worker can then relay this message to Service B. If Service B is temporarily unavailable, Service A’s functionality remains unaffected.

A frequent requirement in Critical Manufacturing MES project deployments is the ability to integrate with external 3rd party systems such as ERP, PLM, or Asset Management applications. To address this, CM MES provides an internal framework and integration engine designed to handle scenarios where asynchronous communication is required or architecturally preferred. The entire process of message storage and processing is managed within the CM MES ecosystem.

At the core of this mechanism lies the concept of an Integration Entry. An Integration Entry can be conceptually compared to a message in an external message queue system like RabbitMQ. It comprises a set of metadata properties and a body containing the message payload, which can be in virtually any format (e.g., JSON, XML, etc.).

In the next sections, we will take a closer look on how this mechanism works, focusing on three key aspects:

• The setup of the process pipeline, from the initial Host execution to the processing of a message.
• The process by which integration entries are retrieved from the database for processing (pulling).
• Important configurations that can be applied to the integration engine or the Integration Entry itself.

But first, let’s have a quick recap of the basic functionality and configuration of the Integration Engine.

Integration Engine Recap

To aid our understanding, let’s refer to the following diagram from the Documentation Portal:

Integration Entries are stored directly within the CM MES database, eliminating the need for external message queues or databases for this mechanism. An IntegrationEntry is an entity type that includes several properties, notably:

• Name: A unique identifier for the integration entry - can virtually be anything, such as a GUID or a consistent naming convention for easy tracking.
• MessageType: Identifies the type of message and is typically used to determine how the integration entry will be processed.
• SourceSystem and TargetSystem: Indicate the originating and destination systems of the message, referencing the IntegrationSystem lookup table. These can also influence the processing logic.
• SystemState: Reflects the current processing status of the Integration Entry (more details below).
• IsRetriable: A flag indicating whether the message should be automatically retried in case of an error.

The actual message payload is stored in a separate but tightly linked entity type, IntegrationMessage, which contains a reference to its corresponding IntegrationEntry.

Integration entries can be created through various means, depending on whether the message is intended for processing by CM MES (Inbound) or for sending from CM MES (Outbound):

• 📨 Inbound: These messages are usually created using the standard CreateObject API or custom APIs that perform initial processing before creating the integration entry.
• Outbound 📨: These messages are created and stored following specific operations within CM MES, typically via DEE Actions or custom services.

The Integration Engine is a background worker framework responsible for processing these entries. We will explore its key components later, but for now, it’s crucial to understand that the engine processes entries based on their SystemState. The following table outlines the main system states of an Integration Entry:

ℹ️ Reprocess Integration Entries
Failed entries can be reprocessed either manually via the System Integration UI Page or automatically using an error handling DEE Action. However, these actions only sets the entry’s IsRetriable flag to True and does not revert the entry’s state to Received. A CmfTimer named RetryIntegrationEntry, running frequently (default every 5 minutes), checks for entries with the IsRetriable flag set. If the maximum retry limit hasn’t been reached, it changes the state back to Received.

Once the integration engine retrieves the next integration entry (or a batch of entries) for processing, it determines the appropriate Integration Package responsible for handling it. An Integration Package is a software library containing an integration handler as its entry point. These packages and handlers are configured in the generic table IntegrationHandler. By default, two integration packages/handlers are registered upon CM MES environment installation:

• SapIntegrationHandler: For direct connection and integration with an SAP instance.
• GenericIntegrationHandler: A versatile handler suitable for simpler integration scenarios.

The mapping between Integration Entries and their corresponding handlers is defined in the smart table IntegrationHandlerResolution. This table allows you to specify which integration package handler will process an entry based on its key properties (SourceSystem, TargetSystem, MessageType).

ℹ️ Integration Packages
In most situations, the GenericIntegrationHandler proves sufficient. This package requires you to specify a DEE Action in the ActionName column, which will be executed to process the entry. You can also specify an IotEventDefinition, although low-code logic falls outside the scope of this post.
Custom integration packages can be beneficial when you need to listen for new messages from external systems like message queues and automatically create the corresponding Integration Entries. This advanced topic is also beyond the scope of this discussion.

Let’s now delve into the Integration Engine in more detail. How does this background worker process initiate? What are its constituent components, and how does information flow within it?

The Integration Engine Pipeline Explained

The Integration Engine pipeline is an integral part of the CM MES Host component. Upon Host startup, the StartIntegrationHandler triggers the background creation of this pipeline. You can verify this process by observing the Starting Integration Manager... entry in the host’s logs during startup.

To better visualize the pipeline’s structure and information flow between internal components, the following sequence diagram provides a high-level overview:

⚠️ This diagram is intended to illustrate the key components and the overall process flow at a higher level, rather than detailing every single C# class or method involved.

Let’s examine these steps in more detail.

Starting the Background Orchestrator

As previously mentioned, the StartIntegrationHandler initiates the Integration Scheduler. The Scheduler’s main responsibilities are:

1. It calls the Integration Manager to load information about the Integration Packages (e.g., GenericIntegrationPackage) from the database and caches it within an Integration Package Registry.
2. It creates a new thread (to avoid blocking the Host’s main operations) that executes the Orchestrator process.

Pulling Integration Entries

Once the orchestration logic begins, it enters a loop where its first task is to retrieve eligible integration entries from the database for processing. This retrieval logic resides in the stored procedure [CoreDataModel].[P_PullNextIntegrationEntry]. This procedure queries the T_IntegrationEntry table and returns one or more integration entries that are ready to be processed.

Analyzing this stored procedure reveals the involvement of another table, T_IntegrationEntryLock, alongside T_IntegrationEntry. This auxiliary table works in conjunction with the main entity table to track the current “processing” status of Integration Entries. When an Integration Entry is created, a record is added not only to the main table but also to this “lock” auxiliary table.

Since Integration Entries are stored in their own table within the SQL Server ONLINE database, it’s crucial to ensure that in environments with multiple running Hosts (e.g., Production), the same entries are not processed by different hosts concurrently. This is why the query employs SQL Hints such as UPDLOCK and READPAST. The UPDLOCK hint applies an update lock to the selected records, while READPAST instructs the query to skip records that already have an update lock. Consequently, if one Host is processing a specific entry, another Host will “read past” it and select the next available entry (or entries).

Furthermore, within the same query, you might observe fields like BatchId and ParentIntegrationEntryId.

Integration entries sharing the same BatchId are retrieved together by this procedure and processed sequentially by the orchestrator. This explains why the procedure might return more than one entry at a time.

The ParentIntegrationEntryId field establishes a dependency chain between entries. If Entry B has Entry A as its parent, Entry A must be processed before Entry B becomes eligible for processing.

⚠️ Parent integration entry might not have been successfully processed
It’s important to note that the system doesn’t inherently prevent the processing of child entries if the parent entry has failed after multiple retry attempts. Implementing a “circuit breaker” or similar custom logic might be necessary in your projects to handle such dependencies and prevent unintended processing.

Dispatch and Process Integration Entries

After the pull stored procedure returns the integration entries, they are dispatched and processed. During the dispatch phase, for each entry, the system determines the responsible Integration Package based on the configuration in the IntegrationHandlerResolution table. Following this selection, the entry and its routing information are passed to the “Process Integration Entry” orchestration method, which executes the actual processing logic.

If the entry is processed successfully, its system state is updated to Processed, and the process concludes for that entry. If an error occurs during processing, the entry’s state is set to Failed. Additionally, if a custom error handling action is configured in the IntegrationHandlerResolution smart table, this action will be executed (e.g., to automatically set the entry to be retried after examining the error message).

Global Configurations and Wrap Up

To conclude this post, I’d like to highlight a couple of global configurations that can be adjusted if needed.

When the orchestrator doesn’t find any integration entries to process at a particular time, it waits for a specific duration before attempting to read new entries from the database again. This duration is known as the Polling interval and can be configured in the Config entry /Cmf/System/Configuration/Integration/PollingInterval/. The default value for this configuration is 60000, which translates to 60 seconds.

Another global configuration is the Number of parallel requests (Config entry /Cmf/System/Configuration/Integration/NumberOfParallelRequests/). This setting determines the maximum number of integration entry processing requests that each MES Host instance can handle concurrently. Therefore, the total number of parallel requests your system can handle is the product of this configuration value and the number of active MES Host instance in your environment. When an MES Host reaches its configured limit, it will stop pulling new integration entries until a processing slot becomes available. The following diagram illustrates an example with two hosts, both using the default value for the number of parallel requests.

ℹ️ One Batch, One Slot
A single batch containing multiple integration entries will only consume one processing slot at a time, as illustrated by the “B & C” example above.

⚠️ Changing default values
In most scenarios, the default configuration values are adequate. However, you can modify these values to better suit your specific needs. It’s crucial to exercise caution when adjusting the number of parallel requests to avoid negatively impacting the system’s normal operation. If possible, it’s highly recommended to conduct thorough load and stress tests in a non-production environment before deploying any changes to these configurations in production.

That’s all for now! I hope this deep dive into the system integration engine has provided valuable insights. If you’re interested in learning more about related topics such as low-code integration, custom integration packages, or anything else, please feel free to reach out!

Author

Hi! My name is Ricardo Cunha. ✌️

I joined Critical Manufacturing back in 2013. I started my journey as a Software Engineer, progressed to Tech Lead, and currently serve as a Technical Architect in the Solutions Delivery area, providing technical guidance for CM MES deployments.

You can check me on LinkedIn