2

A colleague was asking me to explain a system information flow, as they are having problems with the wrong information being presented. It seems that what they have created is a custom built website, with it's own database, which gets it's data from SAP via a JSON based dataset.

SAP is the live information, the custom built solution enables other information to be captured, thereby enriching the SAP data. This is stored locally in the custom site's local database, to produce monthly reports.

I'm trying to wrap my head round why a JSON dataset is being used, rather than a direct (SQL?) query type approach. If the goal is to get live information from SAP on a monthly basis, why not just query SAP, rather than construct a static JSON payload, and have to parse it. Now it seems the argument is whether the JSON wrongly created, or wrongly interpreted... it just seems so much more complicated.

Since the JSON file is done every night too, it's not obvious to me why this particular design has been chosen.

gnat
  • 20,543
  • 29
  • 115
  • 306
Maxcot
  • 157

2 Answers2

0

In the days before ORMs really took off, such an approach was reasonably common. That is: you have a database/programming language agnostic interface such as JSON/XML between the two so (in theory) you could swap out one or the other. Another benefit is that the interface between the two can remain static even if say, a stored procedure changes. You would of course have to change either end, but you'd rarely have to tweak the middleware since it just returned or passed thru a schema or such like.

This is all good in itself but as you've seen, each representation has its own foibles. We encountered a similar problem with one of our systems using a XML payload. It worked fine when the data was fully populated, but would fall over when one of the values was NULL since it wouldn't encode this as an XML node meaning we'd have to supply default values either in the returned data or in the tables themselves.

Robbie Dee
  • 9,823
0

It's hard to say without further information, but it is very likely that it has nothing to do with any "in the days before ORM" scheme. It's likely that someone had to find a compromise between "what the SAP platform (i. e. release) is capable of producing", "what the SAP developers are capable of implementing" and "what the custom system developers are capable of handling". Using JSON (or XML) isn't a bad choice - given the complexity of the average SAP-based solution, you wouldn't get far without additional processing above the SQL layer anyway.

As for the "nightly" approach, that's not uncommon either. Depending on the amount of information that has to be processed and the complexity of processing involved, it might easily take minutes or hours to produce the output - easily longer than the average browser output. In theory, that shouldn't happen, in practice, it happens all the time. Scheduling expensive data extraction processes to run during the night when nobody will be bothered by the added load is fairly easy.

vwegert
  • 101