ArtifactLifeCycle (ALC) is a tool that can be used to analyze any artifact in a retail tech stack. To achieve visibility into any artifact, it needs to be configured with access to all systems related to the artifacts that need to be audited.
- Artifact Type - Artifact type creates a definitive list of possible artifacts which can be reconciled. Establishing an artifact type is important to allow error files to be semantically understood when submitted for review. Without clear artifact types, ALC would be unable to effectively help the user identify further details about it; for example, you couldn’t debug a sales order error without knowing that the data you’re looking at is a sales order.
- Artifact LifeCycle - An artifact lifecycle helps ALC actually understand the full context of how an artifact flows within a retailer’s system. The benefits of ALC understanding the context of where an error occurred in a retailer’s system are vast, beginning with being able to categorize errors and help retailers understand the severity of them.
- Artifact LifeCycle Item - The actual events of a lifecycle which add up to define it place in chronological order.
- ArtifactIdType - Whether the provided ID of an artifact is it’s internal or a commonly known identifier
- System Remote - Defines external systems which ALC is connected to
- SystemRemoteArtifactPath - A registry of how different types of artifacts can be linked in external systems allowing users to directly open a given artifact in that external system.
- SystemRemoteArtifactExternalId - Each system usually keeps a registry of external references to an artifact. This table stores where those references are stored in each system, allowing ALC to jump from one system to another using common reference IDs.
Before ALC can start helping users with debugging errors in their retail pipeline, an Artifact LifeCycle must be set up. To create a LifeCycle, the user will input the following:
- Artifact type that they this lifecycle is for
- Name to help identify LifeCycles with human friendly names when looking at a flow
Once an ArtifactLifeCycle is created, it’s time to start adding LifeCycle Items to it. Each LifeCycle Item consists of the originating system and destination system, from and to, along with a description of what that LifeCycle Item represents. The chronological order of lifecycle events is managed using a sequence ID, allowing the system to understand which step of a LifeCycle is blocked by an error.
When an error occurs in any system of a retailers tech stack, NiFi will be responsible for fetching the error logged data and submitting it to ALC where a user can review it. As a log is being loaded, NiFi is responsible for gathering and including the following metadata for a given artifact:
- Artifact Type
- Artifact ID
- Artifact ID Type
- Artifact ID System (Which system’s ID is being used as the primary ID)
- From System
- To System
- Error Path
The goal of an Artifact LifeCycle Item is to be unique in a combination of the following:
- Artifact Type
- From System
- To System
While there may be scenarios where an artifact flows between two systems multiple times across multiple LifeCycles, the current model is designed with the simple assumption that this level of complexity is rare. When this level of complexity does need to be handled by ALC, each LifeCycle or LifeCycle Item may be appended with another dimension of either “AssocType” or “Purpose” to further subcategories LifeCycles of the same document Type.
Given the assumption that each LifeCycle event is unique on the above listed three dimensions, each error should automatically link to a specific LifeCycle Item and be categorized and searchable for the user based on that.