Skip to Content

Jitterbit MQ (Beta) NACK Activity

Introduction

A Jitterbit MQ (Beta) NACK activity, using its Jitterbit MQ (Beta) connection, negatively acknowledges messages (using the ackId) and is intended to be used as a target to consume data in an operation.

To use the NACK activity, you must first use the Get activity to retrieve the ackId for the message(s). The ackId must be provided in the NACK activity's request schema.

Note

This connector is currently released as a beta version and is available only to a limited set of users. To participate in the beta program or provide feedback on bugs and enhancements, contact your Customer Success Manager (CSM).

Creating a Jitterbit MQ (Beta) NACK Activity

An instance of a Jitterbit MQ (Beta) NACK activity is created from a Jitterbit MQ (Beta) connection using its NACK activity type.

To create an instance of an activity, drag the activity type to the design canvas or copy the activity type and paste it on the design canvas. For details, see Creating an Activity Instance in Component Reuse.

An existing Jitterbit MQ (Beta) NACK activity can be edited from these locations:

Configuring a Jitterbit MQ (Beta) NACK Activity

Follow these steps to configure a Jitterbit MQ (Beta) NACK activity:

Step 1: Enter a Name and Select a Requeue Option

In this step, provide a name for the activity and select a requeue option. Each user interface element of this step is described below.

Jitterbit MQ (Beta) NACK Activity Configuration Step 1

  • Name: Enter a name to identify the activity. The name must be unique for each Jitterbit MQ (Beta) NACK activity and must not contain forward slashes / or colons :.

  • Requeue Options: Select a requeue option, either Reject Messages After NACK or Requeue Messages After NACK:

    • Reject Messages After NACK: This option will reject the previously acknowledged messages and the messages will not be sent back to the queue.

    • Requeue Messages After NACK: This option will send previously acknowledged messages back to the queue to be acknowledged at a later time.

  • Save & Exit: If enabled, click to save the configuration for this step and close the activity configuration.

  • Next: Click to temporarily store the configuration for this step and continue to the next step. The configuration will not be saved until you click the Finished button on the last step.

  • Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.

Step 2: Review the Data Schemas

Any request or response schemas are displayed. Each user interface element of this step is described below.

Jitterbit MQ (Beta) NACK Activity Configuration Step 2

  • Data Schemas: These data schemas are inherited by adjacent transformations and are displayed again during transformation mapping.

    Information

    To use the NACK activity, you must first use the Get activity to retrieve the ackId for the message(s). The ackId must be provided in the NACK activity's request schema.

    The request and response data schemas consist of these nodes and fields:

    Request Schema Node/Field Description
    ackId String containing the acknowledgement ID (obtained from the Get activity)
    deliverTag Integer of the delivery tag (configured as the deliveryTag in a Send activity); for example, if set to 3, messages with delivery tags set to 1, 2, or 3 are acknowledged
    multiple Set to true if multiple messages are to be acknowledged, set to false if only a single message is to be acknowledged
    requeueOptionAfterNack Set to nackrequeue to place the message back in the queue to be consumed by the Get activity, set to nackreject to discard the message
    additionalProperties String containing any additional properties
    Response Schema Node/Field Description
    success Boolean representing the success (true) or failure (false) of the acknowledgement
    error Node containing any errors
    statusCode HTTP response status code returned
    error String containing any error messages
    additionalProperties String containing any additional properties

    Note

    Data supplied in a transformation takes precedence over the activity configuration.

  • Refresh: Click the refresh icon Refresh icon or the word Refresh to regenerate schemas from the Jitterbit MQ (Beta) endpoint. This action also regenerates a schema in other locations throughout the project where the same schema is referenced, such as in an adjacent transformation.

  • Back: Click to temporarily store the configuration for this step and return to the previous step.

  • Finished: Click to save the configuration for all steps and close the activity configuration.

  • Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.

Next Steps

After configuring a Jitterbit MQ (Beta) NACK activity, complete the configuration of the operation by adding and configuring other activities, transformations, or scripts as operation steps. You can also configure the operation settings, which include the ability to chain operations together that are in the same or different workflows.

Menu actions for an activity are accessible from the project pane and the design canvas. For details, see Activity Actions Menu in Connector Basics.

Jitterbit MQ (Beta) NACK activities can be used as a target with these operation patterns:

A typical use case is to use a Jitterbit MQ (Beta) NACK activity in the Two-transformation Pattern. In this example, the first transformation (NACK Request) creates a request structure that is passed to the Jitterbit MQ (Beta) NACK activity. The second transformation (NACK Response) receives the response structure, which is then written to a variable by a Variable Write activity (Write NACK Response) and a message is then logged by the Write to Operation Log script:

Jitterbit MQ (Beta) NACK operation

To use the activity with scripting functions, write the data to a temporary location and then use that temporary location in the scripting function.

When ready, deploy and run the operation and validate behavior by checking the operation logs.