sams-interface-generic-async-process v1.1.6

sams-interface-generic-async-process

SAMS - Generic async process

The purpose of this interface is to centralize bulk events sent by Salesforce to external services or other interfaces, by publishing them to a SNS Topic depending on the target system they aim to send the event. They are then put in a SQS queue on the other side to ensure retry process and a high resiliency.

Develop in local

This interface is testable in local. The whole process will work, except that, at the moment that normally triggers SNS by publishing a message, it will just log "Message successfully published to SNS" and continue process without triggering an error to simulate the normal process.

Pre-requisite : Install serverless globally.

To work in local, follow these steps :

• Copy serverless-private.yml and rename the copy as serverless.yml.
• Comment the line that includes 2way functions :

functions:
  # - "${file(./serverlessSub/functions/2wayauth-private-functions.yml)}"
  - "${file(./serverlessSub/functions/private-functions.yml)}"

• Create a .env file at the root of the project, containing these fields :

STAGE='localhost'
LOG_LEVEL='INFO'
REGION= 'eu-west-1'

• Run npm i
• Run npm run offline

How does it work

The whole system is based on a configuration file config/eventMapping.js. Every object in this call is handled depending on three fields provided in it :

• target : the target system that SF wants to call
• event : the type of event SF wants to send. Basically, one of the target's specific route.
• version : This one is different, it defines a specific version of the target's methoid SF wants to call. This is needed to ensure that, if some day, the target changes one of it's methods version and it breaks the way we call them, this specific message tagged version 1 goes to old version of the target system, and version 2 goes to the new one. This is needed because all this process is async and a message can stay in SQS for hours.

Then, in the same call, SF provides the body they want to send to the target.

Depending on these fields, the process will use a different schema to validate the body, and will send it to a different topic when schema is validated. You need to configure these two fields in the config file, and to put the corresponding schema in the schemas folder. Then, it will work perfectly fine, no code needed.

Here is the technical workflow :

• SF sends in the body of the call an array of this form :

[
  {
      "id": "36db1490-8ca7-476e-acfe-d5f390ba5fc2",
      "event": "activation",
      "target": "neolane",
      "version": "v1",
      "body": {
        "id": "1234abcd",
        ... The body they want to send to the target
      }
  },
  ... Other objects
]

Every object can be for a different target/event/version.

Here is how we handle that in the code :

• For each object of this array, we check the three fields : target, event, version. Depending on these fields values, we check a configuration file to see what is the corresponding validation schema and SNS Topic we need to send the body to when schema is validated.
• We confront the body field to the corresponding validation schema we found with the configuration file.
  • If the body is invalid, we store the info in a report array, flagged with a status 400.
  • If the body is valid, we send it to the corresponding SNS Topic found in the configuration file.
    • If the sending to SNS Topic fails, we store the info in the report array, flagged with a status 500.
    • If the sending to SNS succeeds, we store the info in the report array, flagged with a status 200.
• We scan the report array and evaluate the lambda response according to that. If at least one 500, response is flagged status 500. If at least one 400 and no 500, response is flagged status 400. If only 200, response is flagged 200.
• We send the whole report generated earlier with the corresponding evaluated status as a response.