Context

This page contains a description and visualization of how the instance deletion functionality can be implemented, including the mark instance for deletion feature.

The goal is to agree on the target vision of the process and determine the sequence of implementation by releases.

Refer to Mark for Deletion - Detecting and Resolving Conflicts Requirements for detail.

Inventory Deletion Manager

• I suppose it could be part of the Inventory, but I use a separate name for the new functionality for convenience
• It will need a data storage, business logic and UI for users
• UI
  • Configuration tab
    • User configures which specific dependencies should be checked when deleting an instance for a specific tenant
    • It's like tenant_id ↔ list of module names (or labels), plus maybe date-time of creating/updating
  • Viewing tab
    • Provides a list of all instances marked for deletion
    • Every record contains information about one instance and its dependencies and their statuses (processed or not, what the processing result is etc.)
    • If not all dependencies are successfully resolved, the instance cannot be deleted
    • User can manually set a particular dependency as resolved
    • Once all dependencies are successfully resolved, user can manually and explicitly delete this instance (optional step); automatic deletion by schedule is also possible
• Data storage
  • Keeps configurations and list of all instances marked for deletion
• Business logic

  • A new entry is created when executing mark instance for deletion

  • Handles all events from other modules and monitors the current status of all instance dependencies

Instance deletion workflow (including Mark instance for deletion)

Below is a visualization of the process of processing the mark of deletion on the platform side.

Please note that the mark for deletion event mentioned on the diagram below does not have a specific type; to be precise, this is an update event containing information that the mark for deletion field of a particular instance has been changed from false to true (or vice versa).

@startuml
actor User as User
participant Inventory as Inventory
participant "Inventory Deletion\nManager (IDM)" as IDM
queue "Kafka\n(mark for deletion events)" as K1
queue "Kafka\n(status events)" as K2
participant "FOLIO module" as Module
User -> Inventory : mark instance for deletion
group must be transactional
  Inventory -> Inventory : set flags
  Inventory -> IDM : create a new entry X
  Inventory -> K1 : post a 'mark for deletion' event
end
group repeat for each module in the dependency list
  Module -> K1 : pull new 'mark for deletion' event
  Module -> Module : process the 'mark for deletion' event\naccording to internal logic
  Module -> K2 : post a 'status' event
  IDM -> K2 : pull new 'status' event
  IDM -> IDM : update the entry X
end
User -> IDM : review the current status
@enduml

Textual description of the workflow

• User marks an instance for deletion
  • Three flags are set
    • Mark for deletion
    • Stuff suppress
    • Suppress from discovery
  • Instance is not available for searching and viewing - the assumption is that this is already implemented in Search app, Inn Reach app etc.
  • A new entry is created in Inventory Deletion Manager
  • Inventory posts a domain event with instance_id and other information to Kafka topic
• Other FOLIO modules which have dependency on Inventory, listen to mention Kafka topic, and consume the domain event
  • Every module has its own processing logic (like, update or delete own records, or even do nothing)
  • The only common responsibility is to post an event to another Kafka topic with instance id, module name and processing result (success or fail, maybe some comment as well)
• Inventory Deletion Manager
  • Listens to that another Kafka topic and consumes events from it
  • Looks for a particular record by instance id and updates the status of a particular dependency
• User uses Inventory Deletion Manager at any time to see the current status