Publish Event Smart Service

About the Publish Event smart service

The Publish Event smart service publishes an event to a topic on an external Apache Kafka broker from within a process model. The node uses an Apache Kafka Connected System for authentication and connection details, and supports JSON and Text event formats. Developers can control event routing by specifying an event key, a target partition, both, or neither.

This smart service complements event consumers to provide complete Kafka integration for enterprise messaging. The Publish Event node is compatible with any Kafka-compliant broker, including AWS MSK and Confluent Kafka.

Node properties

The Publish Event node has the following properties:

• Category: Integrations & APIs
• Icon:

• Assignment Options: Attended or unattended

• Compatible with autoscale: Yes

Requirements for the Publish Event smart service

To use the Publish Event smart service, the following requirements must be met:

• Connected system: An Apache Kafka Connected System must be configured with valid connection details and credentials for the target Kafka broker.
• Topic: A Text constant that contains the name of the Kafka topic to publish to. The constant value can be updated during import customization to support environment-specific topic names.
• Permissions: The smart service initiator (or the "run as" user in unattended mode) must have access to the Apache Kafka Connected System and its stored credentials.

Publish Event node

To configure the Publish Event node with the data you want to publish, you'll use the Setup tab and the Data tab.

Configure the Setup tab

The Setup tab provides is where you configure two important inputs: the connected system and the topic. These inputs are static per environment and do not appear on the Data tab.

To configure the Setup tab:

1. In the Connected System field, select an Apache Kafka connected system. The picker only lists connected systems of the Apache Kafka type.
2. In the Topic field, select a Text constant that contains the Kafka topic name (for example, cons!KAFKA_TOPIC_NAME). The picker is filtered to Text constants.

The connected system selection determines the broker connection details at runtime, including bootstrap servers, authentication type, credentials, and certificates. The constant value is resolved during import customization, so topic names can differ between environments without changing the process model.

Each field includes a View/Edit link that opens the selected object in a separate editor window. The link label depends on the user's permission level on the object.

Configure the Data tab

The Data tab allows you to configure the event content and routing, and to map node outputs to process variables.

Configure node inputs

To configure the Inputs for the Publish Event node:

1. In your process model, open the Publish Event node.
2. Go to Data > Inputs.
3. Configure the following inputs:

Input Name	Data Type	Description	Required	Multiple
Body	Text	The content of the event to publish. When bodyFormat is "JSON", the value must be valid JSON. When bodyFormat is "TEXT", any string value is accepted.	Yes	No
Body Format	Text	The serialization format for the body. Valid values: "JSON", "TEXT". Default: "JSON". When "JSON" is selected, the node validates that the body is well-formed JSON before publishing. When "TEXT" is selected, the body is sent as-is.	Yes	No
Key	Text	An optional key for the event, used by Kafka to determine partition assignment. When provided without an explicit partition, Kafka hashes the key to select a partition, guaranteeing that all events with the same key land on the same partition. When omitted, Kafka uses round-robin or sticky partition assignment.	No	No
Partition	Integer	An optional explicit partition number. When provided, overrides Kafka's default partitioning strategy, including key-based hashing. When omitted, Kafka determines the partition using the key (if provided) or its default assignment strategy.	No	No

Configure node outputs

To configure the Outputs for the Publish Event node:

1. In your process model, open the Publish Event node.
2. Go to Data > Outputs.
3. Configure the following outputs:

Output Name	Data Type	Description
Success	Boolean	true if the event was published and acknowledged by the broker; false if publishing failed.
Error	Text	The error reason when success is false.
Published Partition	Integer	The actual partition the event was written to. Useful when no explicit partition was specified. Populated on success, null on failure.
Published Offset	Integer	The offset of the published event within the partition. Useful for debugging and as a unique identifier for the published event. Populated on success, null on failure.

Publish Event node examples

The following examples illustrate how to use the Publish Event node in your process models. The data used in these instructions is for example purposes only. Replace any example data with the data available in your application.

Publish a JSON event to notify downstream systems

Goal: Publish a JSON event to a Kafka topic to signal that Appian has finished processing a request, notifying downstream systems in a pipeline.

To configure the Publish Event node:

1. On the Setup tab, select your Apache Kafka connected system and the topic constant for your target topic.
2. On the Data tab, set the following inputs:
   • Body: Enter a JSON expression that builds the event payload. For example, say your process needs to publish insurance payment data for a downstream payment system. The body of your published events might look like the following:

     1
     2
     3
     4
     5
     6
     7
     8
     9
     a!toJson(
      recordType!CHS Payment(
        recordType!CHS Payment.fields.paymentId: pp!id,
        recordType!CHS Payment.fields.paymentAmount: pv!claimAmountApproved,
        recordType!CHS Payment.fields.paymentDate: today(),
        recordType!CHS Payment.fields.paymentMethod: "ACH",
        recordType!CHS Payment.fields.createdBy: pp!initiator
      )
     )
     

   • Body Format: Select JSON.
   • Key: Enter pv!requestId to guarantee ordering for all events related to the same request.
3. On the Data tab, map the Success output to a process variable (for example, pv!publishSuccess).
4. After the Publish Event node, add an XOR gateway that checks pv!publishSuccess. Route to an error-handling flow when false.

Publish a text event with explicit partition routing

Goal: Route all test events to a specific partition for monitoring with a single consumer during development.

To configure the Publish Event smart service:

1. On the Setup tab, select your Apache Kafka connected system and the topic constant for your test topic.
2. On the Data tab, set the following inputs:
   • Body: Enter the text payload (for example, "Test event: " & pv!testMessage).
   • Body Format: Select TEXT.
   • Partition: Enter the target partition number (for example, 0).
3. Map the Success and Error outputs to process variables to confirm delivery.

Using the Publish Event smart service

The following considerations and behavior apply when you use the Publish Event smart service in a process model.

How Publish Event runs

The Publish Event smart service executes synchronously. The node blocks the process flow until the Kafka broker acknowledges the event or an error occurs.

Delivery guarantee for Publish Event

The Publish Event smart service guarantees at-least-once delivery by ensuring that all in-sync replicas confirm receipt before returning success. If the broker leader crashes after acknowledging, no data is lost.

Appian's built-in retry mechanism handles transient publishing failures automatically. The smart service retries for two minutes before timing out and returning an error. You do not need to configure retry logic for transient errors.

Event routing with key and partition

The Publish Event smart service supports four patterns for controlling how published events are routed to partitions within a topic:

• Neither key nor partition specified: Kafka distributes the event automatically using round-robin or sticky partition assignment. Use this pattern when events are independent and no ordering guarantee is needed.
• Only key specified: Kafka hashes the key to determine the partition. All events with the same key land on the same partition, guaranteeing ordering for that key. Use this pattern when downstream consumers need to process events in sequence by entity (for example, all events for the same loan application).
• Only partition specified: The event goes directly to the specified partition, bypassing Kafka's default assignment. Use this pattern during testing or when routing events to a dedicated consumer.
• Both key and partition specified: The explicit partition overrides key-based hashing. The key is still included in the event metadata but does not influence routing. Use this pattern when you need both a logical key for correlation and explicit control over which partition receives the event.

Error handling for Publish Event

The Publish Event smart service uses output fields for error handling. All exceptions are caught and written to the success and error outputs. The node always completes successfully from the process engine's perspective (that is, the process will not pause with an exception).

You can check the success output and use a branching flow to handle failures. For example, add an XOR gateway after the Publish Event node to route to an error-handling or retry flow when success is false.

Transactionality for Publish Event

The Publish Event smart service acts independently of the other nodes in the process. If a preceding node writes data and the publish fails, the preceding write is not rolled back. If the publish succeeds but a subsequent node in the process fails, the published event is not retracted from the broker.

Related pages

• Integrating with Apache Kafka
• Apache Kafka Connected System
• Event Consumer
• Process Node and Smart Service Properties

Feedback