cancel
Showing results for 
Search instead for 
Did you mean: 

Handling Webhooks with Multiple Payload Schemas (Reprise)

RussellJ
Deputy Chef III
Deputy Chef III

Hi

I was excited to find an EXACT match for my issue (as per the Subject Line) right here... it's just that the response didn't give me enough to get started 😥

I have a SaaS system to which I can subscribe to webhooks.  But there will be a variety of different JSON payloads being sent to my single Recipe, depending on the Event being sent.

Therefore I need to branch my workflow depending on the type of Event/JSON  being received.

When I follow the guided setup for a new Recipe of type "Trigger from a Webhook" it asks for a sample event and then configures the schema of the Trigger accordingly.  But obviously that won't capture the variety of Events being received.

Could someone give me the "dummies guide" to how to achieve what I'm after in Workato?

If JSON Event = "Create" then... {expect this JSON payload and map these values to datapills} and then go do stuff

If JSON Event = "Update" then... {expect this JSON payload and map these values to datapills} and then go do stuff

etc

The bit that's not clicking with me is simply how to replace the single guided JSON mapping for the Trigger with alernative nuanced logic (as above).  There  can be only one Trigger for a Recipe, so how to handle different incoming JSON payloads? I'm sure the "Parse JSON Document" action is involved but I ain't seeing how it comes together! 

It feels like this must be an FAQ, so I think a simple "How To" that others could use would be generically helpful.

Thanks in advance

Russell

1 ACCEPTED SOLUTION

My friend, you may be overthinking this...

From my first response:

I would just ignore the schema entirely and pass the "Payload" object on the webhook trigger into a JSON parser.

The webhook's Payload data pill will be a hash of anything you send to the webhook. It doesn't need to match the input schema.

Here's my webhook trigger, completely undefined other than POST JSON:

webhook1.jpg

Here's my cURL to call it from Terminal:

curl -X POST "https://webhooks.workato.com/webhooks/rest/top_secret/test" \
-H "Content-Type: application/json" \
-d '{"event_type": "do stuff", "anything": "yadayadayada"}'

Here's my JSON parser to capture the event type:

webhook2.jpg

And that's a wrap!

From here you'll have your event type parsed, and then you can route to other JSON parsers. When calling other functions, do the exact same thing as the JSON parser: pass the Payload as .to_json and parse it in the next recipe.

 

View solution in original post

8 REPLIES 8

gary1
Star Chef I
Star Chef I

When using this kind of model, I would recommend structuring your JSON so it's easy to pivot between events.

For example, I always use this format for a basic message queue:

{
  "action:" "porkchop sandwiches",
  "message": "anything at all"
}

Because action is always present you can reliably use its value to control the recipe flow. It's pretty much the same as event type.

Once you know your action/event type, you can throw in a JSON parser for a schema that is specific to the event/action.

I'm assuming this ship has sailed and you're not able to change the incoming format, but the bottom line is that each payload must have some sort of indicator of it's event/action/purpose. Use that value to create different conditionals, and use a schema-specific parser within the conditional.

Hopefully this helps!

And sorry, I may have overlooked the core issue: the webhook requires you to define the schema. 

I would just ignore the schema entirely and pass the "Payload" object on the webhook trigger into a JSON parser.

If you do have a single consistent key across all incoming payloads (like "action" or "event_type"), this should be a cake walk.

If you don't have a single key then this becomes more difficult but it's still completely possible. You'll have to put it through multiple JSON parsers, each configured to look for a specific key to identify the event type (one looks for "action", one looks for "event_type", one looks for "yadayadayada", etc.). Once you get a hit, you'll be able to control the flow.

 

RussellJ
Deputy Chef III
Deputy Chef III

Hey Gary

Thanks so much for you reply!

Yup, I do have a common "action" value across all events/JSON payloads, so that's easy enough for the IF.

And you have indeed come to the core issue - the webhook requires you to define the schema.

The walk is verily CONSTRUCTED OF PURE CAKE... it's just... I still can't see how to stuff the incoming Payload into a JSON parser.  The "Document" field in the JSON parser Action wants to take indiividual fields (e.g. Id and Event) from the output of my Trigger (see screengrab below)... 

json parser.jpg

How do I pass in ALL OF THE JSON PAYLOAD into the Document field of the JSON Parser?

The issue may be caused by my having based this Trigger on the JSON generated by the Guided thingy, I guess? 

You can't have a dynamic sample document, but this is still doable.

Let's say I have a bunch of different events:

// event type 1
{
  "event": "build spaceship",
  "ship_name": "nostromo"
}
// event type 2
{
  "event": "emergency landing",
  "where": "lv-426"
}

// event type 3
{
  "event": "destroy xenomorph",
  "how": "airlock"
}

One option is to make a JSON parser and use a merge all of the different schemas as the sample document. The benefit of this approach is using a single JSON parser but I personally find this difficult and annoying to maintain -- especially when you have more complex events than my example.

{
  "event": "build spaceship",
  "ship_name": "nostromo"
  "where": "lv-426"
  "how": "airlock"
}

Another option is to route to a JSON parser configured to parse the schema of the event. I find this easier to maintain since you don't need to merge multiple schemas. 

If event == "build spaceship" then route to a parser that is set up with an example payload. Repeat this for each event type.

Lastly, once you identify the event type you should route to a function recipe to handle the processing of that event. Try to avoid making a monolithic recipe that handles everything. Break it up, make it modular.