Most of the BAP documentation focusses on applications that are based on the full A12 technology stack.
Nevertheless, there will be projects who want to
- Mix A12 models with pure JSON data received from external sources
- Save some data in a relational database when it’s relational by nature can’t be easily stored in a document DB
- Build a BAP client for an existing non-A12 backend
Is there any documentation on how to do this in a clean way that conforms with the BAP concepts?
@andreas-fresh-mesa eased the situation for claims a bit by defining picus files for external json. Perhaps he can chime in …
For the bap application of <PROJECT_NAME> we also consume the rest api of cosmo. We define document models that match the parts of the cosmo json responses that we need for claims. Note that you do not need to model the whole response. Things that are not modeled are ignored. This makes it a bit easier to work with changing json schema over time, since you don’t strictly need to keep up with every change in the json schema.
The best practice implementing this in the bap would be creating a DataLoader implementation that receives the custom json and then turns that into A12 documents. From there on you can handle it as any other A12 document.
Hi @sfrank_inactive within BAP Client, whenever we would like to access data we want to have our own DataLoader which not require an A12 Document model but your own definition please see <INTERNAL_LINK> for more details.
The code can be found in our sample-application of BAP Client. within section sample-application → src → features → dataWithoutModel folder your question is also mentioned in <INTERNAL_LINK> FQA.
I hope this helps.
HI @sfrank_inactive, we had the same requirements (2 and 3 in your list) , our answers are:
- we are running a project with the properties:
- usuage of a relational DB (which we migth host in the A12 DB but not on relational, not on JSON level)
- connection to external REST services triggered on server side (such as JIRA and directory services)
- (similarly to <PROJECT_NAME> but using the client-server connection of A12/BAP rather than from the client)
- use of BAP with less or no overview model views
- heavily relying on data modeling
- usage of custom client extensions
- the documentation and the quality of the BAP
- is rather low profile (it seems that alternative configurations have not really been considered so far)
- we get great support from @tuan-stable-gale on both topic, emerging
- Baschir and Martin helped on some of these topics, too, thanks
- we are rather slow since we have only one real (smart) worker but part time student, @jerhard_inactive and myself who is in charge for other issues. So we depend evelovement of such documentations.
Would it be also be possible that we could manipulate data sources (thirdparty api, another table…) on server side?
Hi @trinh-wintry-peat. I would say yes you can do it using DataLoader from Client. Since you can implement your own logic, calling to any third-party API
@trinh-wintry-peat If you question is about manipulating remote data (as opposed to only reading it):
In my understanding, the DataLoader does not only load remote data, but is also responsible for saving or deleting remote data.
But I don’t know how to exchange process information about remote operations with the BAP client, e.g. how to handle load timeouts or remote validation errors during save operations.
So my suggestion to the A12 team is to add some documentation about this and also rename the DataLoader so it reflects the actual responsibility of this component (e.g. “Repository”)
I think we should not processing data on client, client should know and contact one endpoint of backend to get data.
If we construct data on client (from different sources: current api, third-party api…), then we need to repeat those stuffs on another client, for example: mobile application, or our api consumers…
Processing data should happen on server side, retrieve data from different sources (from database, from thirdparty api…), then return to client.
Hi @trinh-wintry-peat agree with you 