Or iPhone one-tap : US: +16699006833,,737202874# or +14086380968,,737202874# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923 Meeting ID: 737 202 874 International numbers available: https://zoom.us/zoomconference?m=F0kj5u6u0wFxr7Xfz5NKZxl0xyLhuTPF
approved qty and remarks - these two fields only used during approve process
there is a draft to Requisitions - so to update the approved qty you still need to leverage the draft
approval requisition line item - we'd want an aggregate
status: authorized / approved?
a flag for draft?
We'd need the regular requisition - we'd need it to display the grid
in a batch, some of the columns aren't needed (could we a resource for batch approval)
Next step: create a PoC RESTful design, and present next time
Feature based dependencies
Goal: We want to leverage our service architecture to enable independent:
Develop features in services by different teams
Deploy services based on functionality desired
Why independence?
Development teams may progress independently on services:
build time dependencies don't hold a dev team back (e.g. not every service needs the same version of spring boot).
We may build our Services to turn functionality on/off/do something else should functionality provided by another service we depend on, not be available
Deploying a Service should be a run-time choice for an implementer - i.e. if an implementer doesn't want the functionality some service provides, they should be able to choose not to deploy it.
e.g. I want Requisitions, but I don't want Stock Management, and as an informed implementer I know that means that no Stock Management fields will be available in Requisition if I choose not to deploy Stock Management.
Upgrading a Service, even though the implementation doesn't use it, is a burden on the implementation:
Implementer's time to upgrade, maintain, monitor, etc
Computing Resources
Goal: is to allow for features to turn on/off based on if a Service is available.
Available could mean:
Service was not deployed - this is the one we're trying to solve
Service was deployed, but not serving requests - typical solutions to these include circuit breaker, bulkhead, etc (we don't need to solve for these today)
Service simply isn't reachable
Too many requests
Not yet ready to serve requests
Solutions:
Feature-based dependencies / flags (lack of a better word)
re-uses / leverages RESTful HTTP approach (favored API re-use)
we want to give the implementer and service developer the ability to turn features turn on / off, and we do that by knowing the deployments intent - a Service is available if it was in the deployment descriptor (docker-compose)
we need to spike on how to:
read/write solution (current preferred approach due to race condition using service registration)
read the docker-compose (docker-compose config --services) and create a feature flag based off services deployed
we need to publish (consul KV) those flag statuses and consume those in our services (constantly checking? No, config doesn't change. We want on startup - onetime)
Above reading/writing of these flags to be used in feature-based dependencies is covered in
the above avoids the race condition inherent in using the knowledge in Consul available through service registration,
using service registration in Consul (would be tricky):
could use a timeout solution - we don't have a way in spring boot to actually stop serving requests.
registration could be done very quickly - and so most likely before detection is done, everything is registered.
auth is constantly re-checking consul for services deployed (however how would we solve for the reference UI / keep a consistent user experience across services detecting what is available)
however we don't we don't have a solution to the race condition:
Requisition to Stock Mgmt is a good first step to implement (would spur the discussion about which "features" turn off)
all stock mgmt fields including reasons for losses and adjustments
Equals and hashcode (re-hashed)
Strictly for DTOs, we want to include all properties because we want to generate etags (and most straightforward approach is through hashcode of Object). One of the main issues is the DTOs weren't including the id fields in the BaseDTO.
Did a quick spike in reference data, for dto's not using the id fields. The main issue appears to be some tests that fail because they're using equals methods. Most can be easily solved. One in particular, the Orderables class might not be easy to solve.
Summary: Seems like we're close, but it's not quite trivial work in Reference Data.
General advice is to fix as we go.
if you are implementing the caching strategy, fix DTOs as you go.