We have an integration that is POST'ing messages to a system. Messages are pushed from a publish channel attached to an Object, manipulated with a publish channel user exit before integration script (to add additional data to the payload) and then mapped using JSON.
Ideal Setup:
Our payload from the publish channel is something like the below:
{
"assetnum":"123XYZ"
"siteid":"PHX"
"description":"Cement Mixer"
}
Which is then modified by the script (interacting with the irData object) to the below, wherein some keys are renamed and other appended:
{
"equipmentnumber":"123XYZ",
"siteid":"PHX",
"description":"Cement Mixer",
"header_currentdate":"1970-01-01T00:00:00",
"header_messageid":"123456.98765432"
}
Finally, structured JSON is built using a JSON Mapping in the outbound direction. The OS for this is one that maps out to the ASSET db table. This allows our nested JSON:
{
"equipmentNumber":"123XYZ",
"siteId":"PHX",
"description":"Cement Mixer",
"header": {
"currentDate":"1970-01-01T00:00:00",
"messageId":"123456.98765432"
}
}
attr$equipmentnumber ----> equipmentNumber
attr$siteid ----> siteId
attr$header_currentdate ----> header.currentDate
attr$header_messageid ----> header.messageId
This fails though. The JSON Mapping application requires that any mapping done corresponds on one side to the JSON sample provided and fields that must exist on some parent database object on the object structure. That means that even though we have renamed and added to portions of the payload before it hits the JSON Mapping portion of the code, there is still enforcement of the keys in it only being mappable if they exist on our ASSET Table. This leads up to have to do the following instead as a workaround.
Current Setup:
Our payload from the publish channel is something like the below:
{
"assetnum":"123XYZ"
"siteid":"PHX"
"description":"Cement Mixer"
}
Which is then modified by the script (interacting with the irData object) to the below, wherein some keys are left as they are and other appended. Appended keys MUST match some db field, so we have picked some random ALN fields to use:
{
"assetnum":"123XYZ",
"siteid":"PHX",
"description":"Cement Mixer",
"MODELID":"1970-01-01T00:00:00",
"MOVEMODIFYBINNUM":"123456.98765432"
}
Finally, structured JSON is built using a JSON Mapping in the outbound direction. The OS for this is one that maps out to the ASSET db table. This allows our nested JSON:
{
"equipmentnumber":"123XYZ",
"siteid":"PHX",
"description":"Cement Mixer",
"header": {
"currentdate":"1970-01-01T00:00:00",
"messageid":"123456.98765432"
}
}
attr$assetnum----> equipmentNumber
attr$siteid ----> siteId
attr$MODELID----> header.currentDate
attr$MOVEMODIFYBINNUM----> header.messageId
This works, and is functional. It is however a jarring work around to the issue. For cases where customers are creating user exit classes on their publish channels to modify or add field names, it would be great to be able to map without the requirement a field exists on a parent DB field.