Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

Process Automation 26.2 for Q2 2026 is GA. It’s again a small release after a sneak peek in the release notes, but I quickly saw something great passing by. #SPOILER_ALERT We can now customize our own AI model! ✨ 🤗 ✨

Let’s jump through the list of new functions and features. Take your coffee and cake to consume yourself on this new 26.2 release!

Let’s get right into it…

I did a fresh installation AND I did an upgrade, following my own upgrade post! Why both? Well, because of a too-much-time struggle with the “audit feature” described below on my new VM, while it DOES work on my upgraded VM; Strange!? That’s also the only feature; all the rest is working fine on the new VM, where I don’t need any xECM this time…lucky me! 😅 This post reviews the OpenText Process Automation CE 26.2 Release Notes PDF. I’ll jump through each feature one by one in the following sections.

The quick tag at OT support is #ProcessAutomation26.2!
I always struggle to find the PDF “OpenText Process Automation Supported Environments”; So, here is the link!

🆕 Update on the available changes in 26.2 🆕

We have an AI update again in the pipeline; Hopefully, we’ll make it work! Another breakthrough is the redundancy of the CARS installation…In the future, we don’t need it anymore, as the LDAP entries are saved in the database. It’s a “preview” feature for now, but the basics are working so far. Let’s start with feature #1…

Extensible AI Connector

NICEEEE…

Time to first do a quick search on “AI Connector” in the OPA manuals where you can find this “theory”:

• Create a JAR file implementing ProcessAutomationAIClient; See here for an example on OPA JAR building and deployment. Search for ‘Java Archive Definition’ for more examples.
• Deploy this JAR (via Java Archive Definition) into $CORDYS_HOME/aijars. You can change this (default) location in the wcp.properties with flag: awp.ai.jar.deploy.folder={custom deployment path}
• Make sure to also create these folders; however, I saw them being created automagically too after my first AI call:
  • $CORDYS_HOME/aijars/shared
  • $CORDYS_HOME/aijars/organization
  • $CORDYS_HOME/aijars/organization/{your orgname}
• Deploy all the CAP files for AI power; See also release 24.2 to learn the basics on AI within OPA. Make sure you understand it all first, so you can make a first SOAP call via SendRequestToAI
• In the ‘AI Connector Configuration’ artifact…
  • Under ‘Tools’, add a new entry:
    • Name: Ollama
    • Contract type: Custom (I didn’t try the ‘OpenAI Compatible’ option!)
    • Custom impl. class: nl.bos.connectors.OllamaPlugin
    • Model name: qwen3
    • Model version: 8b
  • Under ‘Applications’, use this new tool as default connection and provide an API key (it’s required, but we don’t need it for our local LLM)
• In the wcp.properties, you can add the Ollama URL (see code below): nl.bos.custom.ollama_url=http://192.168.56.1:11434/api/chat
• You can also set the timeout like this (in the WCP-props): com.opentext.ai.rest.timeout=60. Default timeout is 60 sec.

…

It’s time to put this theory into a practical example with Ollama. I have no clue if it will work, but let’s find out…

First, I make sure OpenAI is working on my VM with a call like this:

1
2
3
4
5
6
7
8

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <SendRequestToAI xmlns="http://schemas.opentext.com/ai/1.0">
      <ApplicationName>OpenAI</ApplicationName>
      <Message>What is the weather today in the Netherlands?</Message>
    </SendRequestToAI>
  </SOAP:Body>
</SOAP:Envelope>

This is my quick config where I get a smooth response:

You can create an API key for OpenAI here

Great, let’s shift gears…

Open the ‘AI Connection Configuration’ artifact again, go to the second ‘Tools’ tab, and create a new AI tool like this:

I don’t know if Ollama is “OpenAI Compatible”, but I’m simply curious about the custom part…try it yourself and comment at the bottom of this post.

Now go to the other ‘Applications’ tab and create a new entry like this:

Ok, fire away:

1
2
3
4
5
6
7
8

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <SendRequestToAI xmlns="http://schemas.opentext.com/ai/1.0">
      <ApplicationName>Ollama</ApplicationName>
      <Message>What is the weather today in the Netherlands?</Message>
    </SendRequestToAI>
  </SOAP:Body>
</SOAP:Envelope>

FAILURE of course with an understandable error: java.lang.ClassNotFoundException: nl.bos.connectors.OllamaPlugin

So, we need to program something fancy like this (no worries; the basics are found in the advanced development documentation too):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

package nl.bos.connectors;

import com.eibus.util.system.EIBProperties;
import com.opentext.processautomation.aiconnector.ProcessAutomationAIClient;
import com.opentext.processautomation.aiconnector.stubs.ApplicationDetails;
import com.opentext.processautomation.aiconnector.stubs.conversations.ConversationHistory;
import com.opentext.processautomation.aiconnector.stubs.conversations.ConversationRequest;
import com.opentext.processautomation.aiconnector.stubs.conversations.ProcessedConversation;
import com.opentext.processautomation.aiconnector.stubs.messages.ProcessedResponseMessage;
import com.opentext.processautomation.aiconnector.stubs.messages.RequestMessage;
import com.opentext.processautomation.aiconnector.util.WebClientUtil;

public class OllamaPlugin implements ProcessAutomationAIClient {
    @Override
    public ProcessedResponseMessage process(ApplicationDetails appDetails, RequestMessage reqMessage) {
        ProcessedResponseMessage responseMessage = new ProcessedResponseMessage();
        responseMessage.setMessage(send(appDetails, reqMessage.getMessage(), 120_000));
        return responseMessage;
    }

    @Override
    public ProcessedConversation process(ApplicationDetails applicationDetails, ConversationRequest request, ConversationHistory history) {
        ProcessedConversation processedConversation = new ProcessedConversation();
        return processedConversation;
    }

    private String send(ApplicationDetails applicationDetails, String payload, int timeout) {
        String ollamaPayload = """
                {
                  "model": "%s:%s",
                  "messages": [
                    {
                      "role": "user",
                      "content": "%s"
                    }
                  ],
                  "stream": false
                }
                """.formatted(applicationDetails.getApiDetails().getModelName(), applicationDetails.getApiDetails().getModelVersion(), payload);

        return WebClientUtil.sendMessage(applicationDetails.getApplicationName(), applicationDetails.getSecrets().getApiKey(), EIBProperties.getProperty("nl.bos.custom.ollama_url"), ollamaPayload, timeout);
    }
}

The implementation class com/opentext/processautomation/aiconnector/ProcessAutomationAIClient.class is part of JAR file /opt/opentext/ProcessAutomation/defaultInst/crosscontext/entityruntime-bean-interface.jar

The only thing we need to do is convert this code part into a JAR on the server at location /opt/opentext/ProcessAutomation/defaultInst/aijars. This is something a ‘Java Archive Definition’ can perfectly do for us:

Notes:

• Do it in a separate project as you deliver JAR files only in the “Shared” package!
• The OllamaPlugin.java file contains the above code snippet.
• That folder structure is important…That’s Java!
• Make lib the “Start Point of Qualified Name” (from the context menu)
• Our new JAR file has a dependency (second tab of the JAD) to another ‘Java Archive’ with this location: ?CORDYS_INSTALL_DIR?/crosscontext/entityruntime-bean-interface.jar

After a valid publication, a double-check of the JAR file on the server, and a restart of TomEE, it’s time for a second call…Well, it’s not an error, but it’s also no response!? Fascinating, as this means our code is at least found! 🤗

Time for a quick remote debugging session over my IntelliJ IDEA; You can learn this JPDA feature (in context of OPA) yourself here. I quickly conclude that we need to update our wcp.properties file with our own custom entry: nl.bos.custom.ollama_url=http://192.168.56.1:11434

AND we need to make sure Ollama is running (to avoid a HttpConnectTimeoutException invoking http://192.168.56.1:11434 HTTP connect timed out) with our qwen3:8b model, and fingers crossed it will all run on my laptop! 🙈 🙉 🙊

When you have Ollama locally running, you can check:

• http://localhost:11434/api/tags
• http://localhost:11434/api/ps
• CMD:

1	curl http://localhost:11434/api/chat -H "Content-Type: application/json" -d "{\"model\":\"qwen3:8b\",\"messages\":[{\"role\":\"user\",\"content\":\"Hello!\"}],\"stream\":false}"

• CMD: ollama list
• CMD: ollama run qwen3:8b
• #RTFM

OHWWW AND…You need to make sure you can access Ollama on your local laptop from your VM (it’s a Windows 11 firewall thing!). You can check with curl http://192.168.56.1:11434/api/tags from your VM!

If it keeps failing, try this in PowerShell:

• setx OLLAMA_HOST 0.0.0.0 and stop Ollama from your Windows taskbar; Start a new PowerShell session (to pick up the environment variable) and start Ollama ollama list; check netstat -ano | findstr :11434 for this value: TCP 0.0.0.0:11434 0.0.0.0:0 LISTENING
• Add an inbound rule to your firewall (with PowerShell):

1	New-NetFirewallRule -DisplayName "Allow Ollama 11434" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow

Time for a third try…with again a step closer to our end-goal…

1
2
3
4
5
6
7

<data>
  <SendRequestToAIResponse xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://schemas.opentext.com/ai/1.0">
    <Message>405 method not allowed</Message>
    <Context />
    <Success>true</Success>
  </SendRequestToAIResponse>
</data>

Could this be because of our required ‘API key’, where we provide ...; Why not put an empty string in our code for sendMessage(...)? All valid questions to get an answer! The answer is simple; It doesn’t matter; My local Ollama is totally ignoring it.

I got the 405 method not allowed because of a wrong URL. I started with http://192.168.56.1:11434, but eventually changed it to http://192.168.56.1:11434/api/chat

My next issue was a timeout thing; the OPA Gateway isn’t receiving a response within 30 sec. from my local Ollama LLM!? Well, what do you expect from a local laptop (running VMs and LLMs)…However, shutting down all redundant apps on my machine eventually brought me to this euphoric moment of the post:

YES…It’s working my friends (after 34 tries)! Running and calling your local AI from OPA; Our next step could be introducing our own Spring Boot MCP Server to let our AI interact with external tools and resources in a structured way!

This is also a great post to read about the MCP topic!

Now the world of AI is at our feet…✨.✦ ݁˖✨

What else? Well, I leave it for another post; It’s on my backlog! Let’s continue to the next new feature…

Audit for exporting list data to file

You can find the enablement of audit in this post. We are curious about this specific setting in the ‘Audit Configuration’ artifact:

Once in place, make sure you have an entity (with some properties), create some instances in runtime, and export them from the list in runtime:

Now, go to the ‘Audit viewer’ artifact and have a look:

It’s a party AND double-clicking the row shows the number of records in the export! 🥳

Next…

Email template for scheduled email notifications

First we’ll make sure to enable mail functionality in our organization. In quick steps, you’ll fix it like this:

1. Start an SMTP server; I use smtp4dev on my local laptop
2. Add a new service container of type ‘E-mail’ pointing to the SMTP server (it’s my local laptop IP)
3. Call a SetProfile service call; this way we know from “whom” we send out mail
4. Create an entity with the ‘Email’ building block in place
5. Call a sendEmail service call to send a mail from an instance of that entity

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<!--SetProfile-->
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <SetProfile xmlns="http://schemas.cordys.com/1.0/email">
      <displayName>OPA Sender</displayName>
      <mailId>noreply@opa.com</mailId>
      <password>PARAMETER</password>
      <userId>opadev@opa</userId>
    </SetProfile>
  </SOAP:Body>
</SOAP:Envelope>

<!--sendEmail-->
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <sendEmail xmlns="http://schemas.cordys.com/entity/email/1.0">
      <ItemId>0800279aadfea1f1912882c221e1b155.327681</ItemId>
      <Email>
        <to>
          <address>john@doe.com</address>
        </to>
        <subject>Hello world...</subject>
        <body>It's me!</body>
      </Email>
    </sendEmail>
  </SOAP:Body>
</SOAP:Envelope>

Eventually, you’ll receive mail like this:

If this goes tooooooooo fast…check this post where we send out a similar mail with SendMail (see the small nuance with sendEmail!) sendEmail is entity instance “aware”; SendMail is not!

…

Now, let’s first make sure we receive notification mails!

The notification BB is pretty picky before it sends something out. I needed to add a role AND also an expression; A simple {true} will do:

Make sure you also apply yourself to that role from the ‘User Manager’ artifact!

Now create an instance of the entity in runtime and watch the log files where I see these entries passing by:

1
2

Missing final '@domain' in string ``true''
The format of the email address is not correct

Weird!? However, “who” sends these notification mails is the great question here!? I would expect it to use the mail config setting you do in /app/admin (see below), but it doesn’t work. What DOES work is the deletion or an update of my entity instance! Without any role/expression, I instantly receive a notification! So, creation is something specific…Not for now! Also, not all notifications drop into my mailbox…Strange! It all feels a bit buggy to me.

…

After a long struggle of playing with settings, I finally get what I want (as a first task event)…A scheduled notification:

This is a default notification mail where someone clearly preferred the old name in the mail subject ‘AppWorks scheduled notifications’! 🤣

These are the bullets I played with before the above came alive:

• Add the ‘Notification’ BB to the entity and eventually also on the related lifecycle task entity (because of the lifecycle; to see if that would work)
• Making sure my account opadev@opa.com has an email address consolidated from OTDS!
• Start the ‘Scheduling’ service container in /system
• Setting the mail settings for the ScheduledEmailNotificationConfig in the solution OpentextEntityRuntimeModelsUtil within /app/admin
• Enabling the ‘Schedule notification’ for the user profile in runtime
• #RTFM in the low-code guide under section ‘Enabling notifications’
• Keeping my fingers crossed at 7:15:00 PM CET

Yes, that’s making a simple ‘Notification’ BB hard to understand and complex to configure!?!?

…

So, all is working now…Let’s tune in to the feature itself! Watch this in runtime:

Open this new entry and update to whatever you like to receive:

Now sit and wait until 7:15:00 PM again OR update the schedule time in your user profile and wait for only 2 minutes:

That’s a ✅ where we learned a lot more about notifications this time…NICE!

My next question would be: What if we create another “Active” scheduled notification template? Is the last one used? Will we get two notification mails? I leave the answer with you to try out…comment below if you find it out!

Web service to share an item with user, group, and role

This is a recognizable feature from a previous collaboration project of mine…Let’s see!

So, make sure you have an entity with a ‘Security’ building block in place and also a ‘Sharing’ BB (incl. an instance role ins_case_share). Enable all the checkmarks for the security/sharing matrix and do your action in runtime with the ‘Sharing’ action button:

Nothing special this far…All out-of-the-box-low-code-stuff!

The “specialty” is in these new SOAP service calls:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

<!--ShareEntityInstance-->
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <ShareEntityInstance xmlns="http://schemas.cordys.com/entity/sharing/1.0">
      <ns0:ItemId xmlns:ns0="http://schemas.opentext.com/bps/entity/core">0800279aadfea1f1912882c221e1b155.327681</ns0:ItemId>
      <Share>
        <UserId>opaadmin@opa</UserId>
        <PermissionName>ins_case_share</PermissionName>
      </Share>
    </ShareEntityInstance>
  </SOAP:Body>
</SOAP:Envelope>

<!--UnshareEntityInstance-->
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <UnshareEntityInstance xmlns="http://schemas.cordys.com/entity/sharing/1.0">
      <ns0:ItemId xmlns:ns0="http://schemas.opentext.com/bps/entity/core">0800279aadfea1f1912882c221e1b155.327681</ns0:ItemId>
      <Unshare>
        <UserId>opaadmin@opa</UserId>
        <PermissionName>ins_case_share</PermissionName>
      </Unshare>
    </UnshareEntityInstance>
  </SOAP:Body>
</SOAP:Envelope>

<!--ShareEntityInstanceWithIdentities-->
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <ShareEntityInstanceWithIdentities xmlns="http://schemas.cordys.com/entity/sharing/1.0">
      <ns0:ItemId xmlns:ns0="http://schemas.opentext.com/bps/entity/core">0800279aadfea1f1912882c221e1b155.327681</ns0:ItemId>
      <PermissionName>ins_case_share</PermissionName>
      <Identities>
        <Identity>
          <IdentityName>Administrator</IdentityName>
          <IdentityType>Role</IdentityType>
          <!--Required for roles; find the value in the identity roles overview-->
          <PackageName>Cordys@Work</PackageName>
        </Identity>
        <Identity>
          <IdentityName>opaadmin@opa</IdentityName>
          <IdentityType>User</IdentityType>
          <PackageName></PackageName>
        </Identity>
        <Identity>
          <!--Create groups in OTDS and consolidate into OPA for usage-->
          <IdentityName>MyGroup</IdentityName>
          <IdentityType>Group</IdentityType>
          <PackageName></PackageName>
        </Identity>
      </Identities>
    </ShareEntityInstanceWithIdentities>
  </SOAP:Body>
</SOAP:Envelope>

<!--UnShareEntityInstanceWithIdentities-->
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <UnShareEntityInstanceWithIdentities xmlns="http://schemas.cordys.com/entity/sharing/1.0">
      <ns0:ItemId xmlns:ns0="http://schemas.opentext.com/bps/entity/core">0800279aadfea1f1912882c221e1b155.327681</ns0:ItemId>
      <PermissionName>ins_case_share</PermissionName>
      <Identities>
        <Identity>
          <IdentityName>Administrator</IdentityName>
          <IdentityType>Role</IdentityType>
          <!--Required for roles; find the value in the identity roles overview-->
          <PackageName>Cordys@Work</PackageName>
        </Identity>
        <Identity>
          <IdentityName>opaadmin@opa</IdentityName>
          <IdentityType>User</IdentityType>
          <PackageName></PackageName>
        </Identity>
        <Identity>
          <!--Create groups in OTDS and consolidate into OPA for usage-->
          <IdentityName>MyGroup</IdentityName>
          <IdentityType>Group</IdentityType>
          <PackageName></PackageName>
        </Identity>
      </Identities>
    </UnShareEntityInstanceWithIdentities>
  </SOAP:Body>
</SOAP:Envelope>

A quick note: Calling ShareEntityInstanceWithIdentities multiple times with a similar identity doesn’t complain, while ShareEntityInstance tells me it already exists!

Due date configuration for a task in a workflow template

This is a runtime feature for ‘Workflow’ creators that have the corresponding role applied to their account. If you also have an entity with the ‘Dynamic workflow’ building block in place, you can now configure your due date for a dynamic workflow template:

When creating an instance out of the dynamic workflow template in your entity, you can manipulate that same ‘Due in’ option. As simple as that! Nothing more, nothing less…Next!

Deployment of Process automation without LDAP - Preview

“LDAP” in this case is our CARS instance on default port 6366, where configuration strings, security constraints, and much more are saved.

You can now install OPA with an environment variable USE_DB_AS_LDAP=true, which makes the installation of CARS redundant and skips the CARS setting in the regular OPA installation wizard. Ok, but where can I now find the entries? Well, they’re now saved in the OPA database under the ldap_% tables.

It’s an interesting step and also a scary one! For performance, I can understand it, but the CARS component is connected across the full OPA platform, where I already found these two issues:

1. Our Cordys Management Console tool isn’t working anymore! It heavily depends on CARS. Start it with command sh /opt/opentext/ProcessAutomation/defaultInst/bin/cmc.sh and tell me where to connect to:

A Postgres connection isn’t working:

I couldn’t find any replacement tool for CMC; I also couldn’t find any migration tool to move from CARS to DB or vice versa!?

2. OTDS consolidation gives an error! Users and groups are consolidated the first time, but the second time OTDS can’t find the UUID (which is normally found in CARS from what I understand):

1
2
3
4
5
6
7

2026-04-23 16:29:30.984|ERROR ||1412976999131784662|4807545431502339270|Push Connector|
Failure Provenance|15,Account Create In Resource||""||""|"Consolidate.
Failed to update object of type __ACCOUNT__ named 'opadev@opa_partition' 
in resource opa_resource (a69a2403-1b85-41b1-b8fb-3ff24962439c).
Reason: com.opentext.otds.connectors.common.MemberNotExistException: 
Error updating member: 404 Not Found An organizational user with the 
UUID '62d40a2a-f741-44ba-9a0b-2549e358b5fd' in the organization 'opa_tips' cannot be found."

For now, I am staying with my CARS instance as it’s also a “Preview” feature.

History building block enhancements – Preview

If you have an entity with the history building block in place, you can use a ‘History’ panel in your layout with a runtime view like this (old way):

To use this new “Preview” feature, you first need to enable it with a feature toggle in the wcp.properties. Add this entry feature.toggle.history.use.newstorage=true, restart TomEE, and check the result in runtime…

That’s a “regular” filter panel…Wonderful job!

Discontinued and deprecated features

There are no discontinued or deprecated features for the 26.2 release, which was also the case in release 26.1.

I give it a “DONE” on OpenText Process Automation Platform 26.2; The playground is open for you to play with all the new fascinating features for this Q2 2026 release. Have a great weekend, and we’ll connect again, next week, with another topic at “Process Automation Tips”.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The Process Automation guy”?