The workflow pods run Liberty, which has no SIBus. The engine's own event queue uses Liberty's embedded messaging inside the pod; external JMS / MQ is configured as Liberty resources through a custom Liberty configuration that the operator merges into server.xml:
# 1. server.xml snippet in a secret / ConfigMap (MQ JMS resource adapter is in the image)
<server>
<resourceAdapter id="wmqjmsra" location="${server.config.dir}/resources/wmq.jmsra.rar"/>
<jmsConnectionFactory jndiName="jms/OrdersCF" connectionManagerRef="cm1">
<properties.wmqjmsra hostName="mq.example.com" port="1414" channel="APP.SVRCONN" queueManager="QM1" transportType="CLIENT" userName="mqapp" password="${env.MQ_PASSWORD}"/>
</jmsConnectionFactory>
<jmsQueue jndiName="jms/OrdersIn"><properties.wmqjmsra baseQueueName="ORDERS.IN"/></jmsQueue>
<jmsQueue jndiName="jms/OrdersOut"><properties.wmqjmsra baseQueueName="ORDERS.OUT"/></jmsQueue>
<jmsActivationSpec id="bpm/OrdersInAS"><properties.wmqjmsra destinationRef="jms/OrdersIn" hostName="mq.example.com" port="1414" channel="APP.SVRCONN" queueManager="QM1" transportType="CLIENT"/></jmsActivationSpec>
</server>
# 2. reference it in the CR
spec:
baw_configuration:
- name: bawins1
# reference the secret with the custom Liberty configuration (field name per release: see the CR reference, "custom Liberty server.xml")In the process app nothing changes: the JMS Send integration references the connection factory and queue by JNDI name, the inbound side is the same Undercover Agent bound to the inbound event; the eventmsg XML format is unchanged. MQ connection details differ per environment, so keep them in the Liberty config of each namespace (or use environment variable substitution as above with a secret mounted as env). Kafka is the newer option on the Cloud Pak: BAW 21.0.3+ can start processes / raise UCAs from Kafka topics through the Kafka event integration (the workflow Kafka connector configured with Business Automation Insights' Kafka), which avoids the resource adapter setup entirely.
References