Reference data, such as Programs, Facilities, etc. are currently found in the Requisition service. This is intentional, to avoid complicating the application with numerous services early in the project.
Reference data domains are identified
Reference data domains moved into a separate service, with all the normal build infrastructure.
Other services (requisition, auth) must be updated to invoke the new service.
Design and implement a common utility to get (and set?) objects from other services (see Sebastian's idea of a 'getter' utility on the forum).
Design (and possibly implement) a caching strategy and mechanism, to avoid continuous redundant reads from any service. Consider some domains/data are more volatile than others. This can be a separate story.
<new in sprint 8>
Based on the dev listserv discussion here the following should be followed. and please let me know if this is the appropriate story or if we should create a new one. I just want to make sure this is being captured in the appropriate story.
• The requisition service stores just UUID references to reference data.
• No caching (yet). In the first pass, make a request over the wire every time you need a piece of reference data.
• No snapshots/versioning (yet).
• No automagic getters (yet?)
These simplifications will allow devs to play this story much faster, while focusing on only what's truly necessary to separate the services, and write appropriate tests. And then we can bring back the complexity piece by piece.
1. I can't update my productCategories using /productCategories/id endpoint.
2. I can't list all productCategories using /productCategories/search endpoint.
3. The /facilities/supplying endpoint displays all facilities when programId and supervisoryNodeId are invalid.
I still have a problem with update my productCategories using /productCategories/id endpoint.
we do not want to update the code for the product category. If that's the only issue, we should to close this ticket