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 asserverless.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 thebody
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 areport
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.
- If the sending to SNS Topic fails, we store the info in the
- If the
- 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.