Overview of AWPF message types
Basic concepts of your asynchronous workload and the different options available to process them consistently and under very high throughput requirements.
This article describes the concepts of InboundMessageType and OutboundMessageType entities and explains the importance of key fields in this entity that will help you configure the inbound and outbound traffic for a Manhattan Active® Platform microservice.
Fields of InBoundMessageType
| Field | Description | Default value | Recommended value |
|---|---|---|---|
| MessageType | Message type for Inbound. This serves as the business key for the entity along with the profileId. InBoundMessageType is a config type entity, belonging to messaging profile purpose. | N.A | Some name that explains the business purpose of the inbound |
| Description | Functional description of this messageType on its usage. | N.A | Describe the business purpose of the messageType in clear words. |
| NoOfConsumer | The number of concurrent consumers to be started in a high volume stereotype instance like a QUEUE_PROCESSOR | null | Depends on the business usecase. Any QPROC coming up for this messageType will have this number of consumers. The value should be judiciously put based on the volume consideration. For a fairly high volume queue, it should be in 10s at least. |
| MinNoOfConsumer | The number of concurrent consumers to be started in a low volume stereotype instance like a LOW_VOLUME or ALL | null | null / 1 If it is set to null, then it is considered to be 1. It should not be more because generally the low volume instances listen to all the queues and adding more consumers just adds to the number of threads running in the container and may not actually help in scaling the queue processing. 0 The value should be specifically set to 0 in case you do not want any low volume instance to listen to this messageType. Only QPROCS will be able to process this messageType. |
| ServiceId | Service Id mapping to the ServiceDefinition that performs the actual business logic for this messageType. | N.A. | Should be the serviceId(mapped to a ServiceDefinition entry) that is supposed to process the message. |
| Idempotent | Flag to ensure the message is not processed multiple times on the consumer side. False value means it cannot be processed more than once. Should be used judiciously as it adds extra processing on the system as AWPF has to keep track of the processed messages in the database. | true | true (Unless your business usecase forces processing of the message only once. But if you mark a messageType as non-idempotent, please make sure you generate a messageId for the message on your own (on the producer side application code). Else, the framework generates a messageId on its own. This will not serve the actual purpose of a non-idempotent message as AWPF identifies a message with the messageId. Two identical messages (in terms of content) but having different messageIds will be treated as different messages by AWPF and will be processed separately.) |
| RetryCount | Maximum retry count for a message to process. You can override the system property level default retries for your messageType with this property if there is a need | 3 | 3 |
| RetryDelay | Retry delay for a message to process. Earlier the default retry delay was set to 500ms between each retry as a system property and all the messageTypes had to follow the same pattern. You can override the default by providing a comma separated list of retry delays (for each retry loop) for your messageType. | 20,300,600 | 20,300,600 Unless there is need for your messageType to change the default delay in each retry loop. |
| PreFetchCount | Prefetch count for a message type to process. This field lets the user override the default prefetch count set the brokerCluster level at the messageType level | 50 | 50 (Unless your messageType is fairly low volume and heavy processing one. If you have very less number of messages coming in but each message takes a lot of time to process, it is better to set low prefetch count to utilize all the available consumer threads. Else, 50 messages will be given to one consumer thread and other threads will remain idle. Scaling up the processing with QPROCS also will be problematic as very less messages will be in ready state and most of them will be stuck in the unacked state for a long time.) |
| BrokerClusterName | Used for setting up non-default broker properties. This property maps to the InternalBrokerConfig entity where the broker specific producer URI, consumer URI and other parameters are defined. | null | null (Unless your messageType requires to have a specific broker (like Kafka, SQS, Google pubsub) or you want to override specific properties of the default broker setup. Default NULL would mean RabbitMQ.) |
| BusinessKeyPath | A JSON path that points to a field on the payload Document that will be sent to this message type. In the event of a failed message, AWPF will evaluate this JSON path and send the value along with the failed message. When CommonUtil listens to the awpf-reprocess queue, it will look for this field and save it on the BusinessKey column in the failed message table. In the event of a batch job message failure, AWPF will evaluate this JSON path and save it on the UniqueIdentifier column in the batch processed message table | null | null (This field is used to quickly show the user messages that have failed for a specific business key. As such, if you want to make use of this feature, you should provide a JSON path that makes sense to the payload that will be processed by this MessageType.) |
Fields of InBoundQueues
This table is an optional child of InBoundMessageType where you can define explicit queue names
| Field | Description | Default value | Recommended value |
|---|---|---|---|
| QueueName | If you want a specific queue name for your messageType and do not want AWPF to decide the queue name based on your messageType. This is helpful when you have to keep the same “messageType” property in multiple components, but every component has its own queue for this messageType. Mostly used by frameworks. | N.A. | N.A. |
| FullyQualifiedQueue | In a org-specific environment setup, each messageType corresponds to multiple queues, each queue belonging to a different organization that shares the profile. AWPF prefixes the derived queue name with the organization id to make the actual queues org specific. But, if you do not want AWPF to add any suffix and you want to keep the exact queue name you specify, you have to set this flag to true. This is mostly done while connecting to a SQS or pubsub topic where the queuename is part of the handshake with the third party. | false | N.A. |
| FullyQualifiedQueueV2 | Applicable for a multi-tenant environment. Value of true implies that no prefix including the tenant id should be added to the queue name | false | N.A. |
Fields of InBoundMsgToRetransmit
This table is yet another optional child of InBoundMessageType. This will be used to route the inbound message to another queue, without processing it in the current consumer.
| Field | Description | Default value | Recommended value |
|---|---|---|---|
| ToMessageType | Maps to the outbound message type where the message will be retransmitted. This is mostly used for external integration. Say you are connecting to SQS/ Googlepubsub through XINT component but the actual processing of the message will happen in some functional component (like order or inventory). The inbound messageType connecting to SQS/Pubsub should be created in XINT and then the message should be retransmitted one of the internal RabbitMQ queues which will be consumed by the functional component. This is the recommended way of connecting to external brokers for ease of scaling. | null | N.A. |
| TransformServiceId | Maps to a service definition service id which will perform data transformation before retransmitting the message | null | null () |
Authors
- Subhajit Maiti: Director, Manhattan Active® Platform, R&D.
Feedback
Was this page helpful?
Last modified April 25, 2024: Update deploy.yml (aa43072)