...

...

1. mod-inventory-storage tracks changes with instances, holdings and items on its side and publish so called domain events to particular Kafka topics (note: directly to Kafka, not via mod-pubsub)
   1. Kafka topics used for domain event publishing - inventory.instance, inventory.item, inventory.holdings-record
      1. Note that particular Kafka topics naming convention is to be followed

         Jira Legacy
         server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINVSTOR-738

   2. On FOLIO side there are such types as instance, holding, item. On INN-Reach side there are such types as bib, item. Basing on their sense, 2 pairs are formed - instance↔bib and item↔item - Brooks Travis , could you confirm this please.
   3. Refer to SPIKE: [MODINREACH-22] Verify Inventory Domain Events Published for Remote Storage and Elasticsearch Can be Used to Trigger Updates to Bibs and Items for more details including content of domain events
2. mod-inn-reach connects to mentioned Kafka topics directly with a dedicated consumer group and consumes those domain events
   1. note that a separate consumer group allows to consumer events from Kafka topic without interception with other consumers
3. A domain event only contain a part of details about instance / item, in particular tenant, event type, instance / item ID. So, mod-inn-reach is to request all other required details from mod-inventory using mod-okapi and FOLIO Platform API (point 3.1-3.3)
4. Then mod-inn-reach retrieves required configurations and / or mappings from its own configuration data
5. Optionally, mod-inn-reach authenticate API if need (refer to D2IR API Authentication flow for more details)
6. mod-inn-reach invokes an appropriate D2IR API endpoint (refer to API specification and D2IR endpoints - implementation status)

...

Refer to

...

Proposed Work breakdown structure

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-78

  Spike #1: Analyze domain event pattern implementation in mod-inventory-storage and mod-search
  • Basically, mod-inventory-storage is a publisher, and mod-search is a consumer (pretty similar to mod-inn-reach); so the goal is to see how they are implemented in code
  • Expected outcome - code is analyzed and is clear for development team

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-79

   Spike #2: Analyze data required for D2IR contribution
  • One need to review what data is required for D2IR contribution and verification of contribution criteria, and map them on data from FOLIO inventory and SRS
  • Expected outcome - all fields are mapped

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-57

  Analyze how to retrieve and transform MARC record

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-80

   Spike #3: Analyze Re-Index job implementation / usage in mod-inventory-storage and mod-search.
  
  • Open question: should the same topic but new event type be used, or does dedicated topic fit better? (RA: i'm not a fan of making separate topics per every case but here it seems to be safer in order not to impact on other consumers... though for Kafka itself and its clients it should not be a problem to filter out events with unknown event type...). One more note: having 2 topics allows to manage them - e.g., process full contribution first, and after that only continue with regular contribution
  • Open question: does it make sense to implement an mod-inventory-storage endpoint accepting a condition(-s) for filtering out events?
  • Expected outcome - development team has understanding what should be implemented to start or cancel re-iteration process in mod-inventory-storage

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UX-443

  Create UX mock-ups for Initial / Partial Contribution settings
  
  • Expected outcome - clear and detailed mock-ups are available

...

• (mod-inn-reach) Enrich domain events with additional information from SRS
  • More details are to come from Spike #2
  • Expected outcome - mod-inn-reach has all the information required for D2IR API and available in SRS

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINREACH-48

   Implement MARC analysis
  • Contribute Bib endpoint needs marc21 bib data in ISO2709; current vision is that only those instances that have associate MARC data in SRS can be contributed
  • decode MARC record, update in to align with D2IR specification requirements (check 008 and 245 fields are presented, omit 9XX fields), encode to MARC again, encode in Base64
  • Expected outcome - MARC record fully complied with D2IR

...