Orchestrating a legacy back end: service bus, JavaScript policy, or Node.js?

Not applicable

An Apigee customer asked me for advice on how to implement a requirement. I want to see what the community suggests:

We have a requirement to call a backend system in a loop and put the responses together and send to the client. Each loop in this case might take several seconds as it’s hitting a legacy backend. It’s a mix of orchestration and looping where each loop makes two different calls to the backend and puts the responses together and then again mashes the responses after the looping.

They use Edge and have an enterprise service bus. There is debate about where to put this logic. Does it belong in the service bus or would it make sense to implement it in a JavaScript policy or maybe a Node.js application? How do you feel about having complex logic in Edge? Does your team find it’s easy enough to test, debug, and maintain the code?

5 8 1,094
8 REPLIES 8

the described usecases seems to be a good fit for nodejs [or code] - similar logic could be difficult to configure even in a ESB with all the graphic tools for BPM or BPEL or Flows even within Apigee

So if it's a code vs config question - I would chose code and would prefer nodejs [request, async modules can make implementing such logic much much simpler]

to the second part of the question - where do you want to run this? Apigee or the ESB

If it is just about orchestration and mashup [loop, combine responses, transform or filter data etc..]- I would prefer doing it in Apigee

If it involves any business logic [if x > y then call B else call N etc..]- its better to manage at the business process layer [typically a BPM or BPEL in ESB or an application system], so you could decouple exposure and consumption and take advantage of 2-speed IT

Now to the last part of the question on test, debug and maintainence - assuming you use nodejs and apigee , it fairly straight forward.

Development and unit testing is done locally

At runtime, you have access to nodejs script logs, access to context variables and more importantly as a programming language you have lot of flexibility to handle exception and failures, write debug logs for troubleshooting

you should treat this code thro the same CI/CD process as how you would manage other existing code bases in your enterprise,

This is very helpful. Thank you.

Not applicable

Hi @kdanekind1

I am currently working on a project that has a requirement similar to that you describe.

We have two situations where we needed to loop calls to the back-end:

  1. The responses are paged but the client requires a single response (the first response is the first page but also provides the maximum number of pages)
  2. Cache prepopulation - looping across a range of parameters (in our case sales territories) including some that are paged as per 1. above and making cache entries with the responses including combined paged responses

The implementation we chose was to perform this in a nodejs target deployed to Edge.

From a development and testing perspective, we were able to work locally and being nodejs it can be run standalone and verified before being deployed to Edge.

Why did we choose node.js?

Mainly because we couldn't see how to make it work with policies alone and our Java skills are lacking (some might say that about my node.js also!)

We didn't consider doing this at the back-end mainly because of time to develop the solution.

I think @Mukundha Madhavan makes a good point about choosing the back-end/ESB where the orchestration across services is driven by business logic vs apigee where it's about mashing responses together. In our case the looping and orchestration is about combining responses so that fits in with this view.

A word of caution on node.js with apigee

The back-end services we have are SOAP services and for this project they are serving up data from our SAP BI database.

We reached a point where some of our responses were timing out. This caught us by surprise because testing locally with node.js they were acceptable (to us) at the 10-12 second mark.

Deployed to apigee they were taking 60-70 seconds and in some cases longer than that such that there was never a response.

After some apigee support tickets this was narrowed down to the performance of the XML parsing in node.js when running with trireme on Edge. It's possible to run locally with trireme - I recommend that if you're intending to deploy the node.js to Edge so that you are aware of possible performance problems ahead of time.

The other things to consider when looping with node.js:

Do you wish to respond to the request immediately and let node run as a background task or do you need to wait until all the responses are received before responding?

We ended up with both - the prepopulation of the cache became a "background" task but the client got an instant response to indicate that the request was received and prepopulation was in progress. The "regular" calls wait for the combined response.

If you end up with a "background" task that's a long running task (i.e. longer than your client is prepared to wait) then how do you keep tabs on what node is doing?

We opted to write some things out to the node.js logs in apigee but also to loggly. Using an external logger like loggly just makes it much easier to see what's going on and to be able to search/filter the log.

Wait a minute! No solution to the performance problems?

We resolved the node.js performance problems with the help of apigee. @Sean Davis, @ncardace, and Deepak Sharma have provided great assistance (Thanks!).

For the calls that performed poorly, we now have a solution that uses Javascript policies to make the calls to the back-end.

For cache prepopulation, two js policies handle the looping across pages with a node.js target solely to put the responses in the cache.

For "regular" calls we had to redesign a little so that we cache by response page and the client handles the mashup. This deviates from what you require I think, and it did for us too, but the performance gains from using Edge policies have been worth it.

So, we have a node.js solution and an Edge policy solution side-by-side achieving the same result of looping calls to the back-end services.

I haven't quite answered your question directly but hope that the brief description of what we have done and experienced helps in the decision making.

A massive thank you for sharing this @neil.munro! This project allowed us to push the limits of the Trireme engine and challenged the way we usually approach Node JS API design. I look forward to sharing this write up to others that are tackling similar use cases.

This is very helpful. Thanks!

Neil,

60 seconds! Wow!

how large were the XML docs you were parsing in trireme (nodejs in edge)?

Hi @Dino

When saved to file the XML docs are not massive.

The problems started with a payload size of about 50KB but some are 400 or 500KB+

The small 50KB file equates to about 9000 database records with about 25 fields each.

We were using npm's "soap" library that includes the conversion from XML to JSON and relies on sax under the covers for xml parsing.

The client application requires csv so we were doing the JSON to csv conversion in node also.

Moving to calling the back-end directly from Edge and using the XSL policy for XML to csv makes such a difference for our particular implementation.

great question, Keith! I have a strong bet that the answers I see will start with "It depends..." !! 🙂