4

We are supporting data exchange in JSON, XML and SOAP for our customers. The bird view of the data flow would be like this

  • Partner 1 sends request for some data with XML data
  • Partner 2 sends request with JSON
  • Partner 3 sends request with SOAP

To have a general approach for all partners. We have created a file for each partner where we are defining the partner's parameters and our corresponding parameters.

After getting the data required we process the data and generate a response. This response has to be sent to partners in their respective formats again. For that, we have templates where we just fill the response data into the template and sent that to the partner.

How do you normally solve this problem?

What am I working on? I am creating a generic parser which transforms partners request into our required format with the help of the file we have with parameters.

  • Routing - xform - it is a broad question ... ever thought about ready made solutions? Websphere mq, Extricity ... ? – YoYo Mar 12 '17 at 2:45
  • It would really depend on the language and framework you're using. C# webapi is specifically targeted for this by separating concerns - it relies on Content-Type header in the request and parses the data using appropriate parser as registered on app startup. The business logic then works with simple object classes with properties, so it doesn't care what format the request came in. Likewise, it can use the Accept header to render the result in the expected format. So this way they can send SOAP and receive JSON in the same request. – zaitsman Mar 12 '17 at 8:25
4

You use a very valid approach, but your question is quite broad: there are plenty of ways to handle it. The right answer will depend heavily on your existing architecture.

My first guess would be to:

  • use a strategy pattern for format dependent parsing;
  • use a strategy again for generating the answer (if the template approach would no longer be sufficient)
  • if needed, put a format selector in your parser output request in order to keep track of output format to be used for sending back the answer.

If an ad-hoc parser is not sufficient, you could use out of the box parsers, and handle the different parsing events in a way to build an homogeneous format independent request object (i.e. The requests could be implemented using the command pattern, which when carried out will execute the request and produce the answer).

P.S: I understand that your system carries out some kind of transactional processing, and that the parsing is more about getting the parameters/arguments of the transaction than elaborate parsing of complex requests. This is why I didn't suggest the interpreter pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.