Cloud Adapter Registration

Client Applications that integrate with the Common Core Platform in the Cloud tier must be registered before they can send or receive messages. Unlike Site and Central tiers, registration in the Cloud is managed via an API rather than JSON files.

Registration API Overview

The Drex Adapters API provides five operations for managing client applications:

HTTP Method | Operation Name | Endpoint

POST | Create Client Application | /drexadapters/apps

DELETE | Delete Application | /drexadapters/apps/{appName}

PUT | Full Update | /drexadapters/apps/{appName}

GET | List All Applications | /drexadapters/apps

PATCH | Partial Update | /drexadapters/apps/{appName}

API Documentation:

Drex Adapters API

Registration Workflow

# Step 1: Check if the Application Already Exists

  • Call the GET operation with the application name to search for existing registrations:

GET /drexadapters/apps/{appName}

  • Evaluate the response:

  • If the application is not found: Proceed to Step 2 to create it.

  • If the application exists but has incorrect settings: Use the PATCH or PUT operation to update it.

  • If the application exists and matches the required settings: No further action is needed.

# Step 2: Create or Update the Application

  • Create a new application (if not found in Step 1):

POST /drexadapters/apps

Example payload:

{

"Name": "adv.analytics",

"Ver": "1.0.0",

"Direct": {

"Enable": true,

"EnableFeedback": true

},

"Broadcast": {

"Enable": true,

"Topics": [

"abs.cc.vesselreport",

"abs.cc.tenants"

]

}

}

  • Update an existing application (if settings are incorrect):

  • Use PATCH to modify specific fields:

PATCH /drexadapters/apps/{appName}

Example payload:

{

"Broadcast": {

"Topics": [

"abs.cc.vesselreport",

"abs.cc.tenants"

]

}

}

  • Use PUT to replace the entire object:

PUT /drexadapters/apps/{appName}

Queues Created for Each Application

Once registered, each application is assigned three queues:

Queue Type | Queue Name Format | Purpose

Broadcast Inbox | q.cc.drex.inbox.broadcast.adapter.<appName> | Receives messages sent to topics the application subscribed to.

Direct Inbox | q.cc.drex.inbox.direct.adapter.<appName> | Receives messages addressed specifically to the application.

Feedback Inbox | q.cc.drex.inbox.feedback.adapter.<appName> | Receives feedback messages for undeliverable Direct messages (optional).

Broadcast Topics

To ensure proper routing of broadcast messages, the topic must be specified in the Broadcast.Topics array during registration. Messages without a topic will not be delivered to the broadcast queue.

# Common Topics

Topic Name | Description

abs.cc.vesselreport | For vessel report messages.

abs.cc.tenants | For tenant-related updates.

Best Practices

  • Register During Deployment

Perform registration during the client application’s deployment or installation process to ensure the application is ready to send and receive messages.

  • Validate Before Creating

Always call GET to check if the application already exists before creating a new one.

  • Use Partial Updates for Small Changes

Use PATCH for minor updates to avoid overwriting unrelated fields.

  • Monitor Queues

After registration, verify that the expected queues are created in RabbitMQ.