I keep running into the same transformation problem in Jitterbit. At one end I have an array of nodes/rows/textlines on the other end I have an JSON rest api which only accepts one item per request.
What you would normally do is this: Turn on the Jitterbit chunking options in your transformation and make sure only one request is made per row iterated. Each row processed will be posted directly to the endpoint.
But unfortunately In this case with a single call API it will not work. It only works if my output format is an array of JSON object and not a single object.
Let me demonstrate with the following example:
- I have a csv file with multiple orders
- I have an endpoint for posting an order
- The endpoint can handle just ONE endpoint at a time.
Functionality we want to achieve the following: For each ORDER in my ORDERS csv I need to post to a JSON rest api.
Solution 1: iterate + subflow
We create a transformation and use this as an outerloop. For each record we will make a call to a suboperation. The suboperation posts the json to our endpoint. This is the classic way of handling this scenario.
You can download the iterate sublow solution in the Jitterpack here.
- Easy to setup
- Tried and tested in production
- Each property which we need to use in the suboperation needs to be defined in a variable. This can be quite cumbersome and error prone.
- It’s not possible to test this with the Jitterbit debugger (at least I wasn’t able to). Making it a lot of work to debug and test the sub operation.
Solution 2: iterate output array
In this scenario we are going to first convert the CSV to an Array of objects. Then we are going to loop over this array of objects. And for each object in that array make the call to the ORDER endpoint.
Download the Jitterpack containing the iterate array solution here
- We will only need one mapping
- Our logic will be inside of our controller script instead of a condition in a transform
- No more variables needed to make the call to the subflow.
So what is so special about this approach. Good question!
First of all: we are running everything in the controller code so we can test everything end to end before we migrate to production.
Secondly: this solution means you don’t need to define lot’s of variables for each sub transformation. This makes it easier to maintain (no more hidden variables in the transformation) but also easier to change. Adding a new field to the JSON doesn’t mean going over a hundred variables.
- Transform CSV to a JSON array
- Loop over this list of JSON objects
- For each item post to the endpoint using a standar Jitterbit operation with drag and drop mappings
Here is what the solution looks like in detail:
Parsing JSON to an Array: