Versions Compared

Old Version 30

changes.mady.by.user Ingrid Oliversen

Saved on

compared with

New Version Current

changes.mady.by.user Ingrid Oliversen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The target queue can live in two difference places:

  1. in your own AWS account

...

  1. . This

...

  1. gives you as a customer the most flexibility.

  2. in DI's AWS account. A fee will be charged in this case to cover administration and operating costs. For this option reach out to you contact person to plan.

The events will be represented in the same format as used by the Parcel Event Log v1 API, but not including all fields/values.

Info

  • Clients using this API should not fail if new fields are added to the response. If a new field is added to the response on a later stage, existing clients should handle this in a way such as they just ignore the field.

  • Fields not set in the response are not left out, that is fields in the response may have null values. E.g. "shipmentNumber": null. The client using the endpoint should handle this.

  • Event may be delayed for a short periode of time and events may come in incorrect order (e.g if there are delays from a specific source). Clients should handle this by using the event time specified for each event, and not necessarily present them in the order they are received.

...

  • ensure your organization is ready to process events: fetch them from the queue, parse them, and process them.
    See [1] for a list of available implementation technologies from AWS. Examples are included in the SDK documentation.

Option 11a

  • (preferred) provide the destination AWS default type SQS queue ARN (FIFO queues are not supported)

    • grant DI access to your queue (see section below)

    • confirm the subscription to the SNS topic for your SQS queue after DI has enabled the feature (see [2]). You need to find and visit a subscription confirmation URL inside a message posted to your queue.

    • if you can't find subscription confirmation message, double check the policy to ensure DI is allowed to write into your queue and ask DI to resend the confirmation message

    • This option includes automatic retry logic if you queue for some reason is unstable

Option 2 1b

  • (preferred) provide the destination HTTP/HTTPS protokoll endpoint (e.g. from google cloud services)

    • Whitelist DI to give access to send information (see section below)

    • Make sure your endpoint accepts messages in text format

    • Confirm the subscription to the SNS topic for your endpoint after DI has enabled the feature (see [2]). You need to find and visit a subscription confirmation URL inside a message posted to your endpoint.

    • For http/s we will handle a maximum of 3 retries.

...