Document PLM Life-Cycle Attributes and Models

Admin
Post Views: 680
Print Friendly, PDF & Email

Document PLM Life-Cycle Attributes and Models

In this Blog I want to discuss the attributes and models that will drive the document storage and retrieval between the server and client sides. Before we get to far we have to cover one last issue, the file name conundrum.

Filename Attributes

So what is the problem, people are the problem, when we create files we always give the file; a name that we can go back to either a day later or a year later and know what that file contains based on it’s type and name. So how are we going to handle this with the automated storage solution we want to work on?

Attributes are name : value or key : value pairs that provide critical information about something, and we use this all the time since its the foundation of descriptive conversation. For example when we talk about a car we might say Color : Red, or Horse Power : 380, and so on. The same process will help us describe and track a file, in the following sections we will try to break down what attributes we think were going to need to make this process work.

Version

So lets start of with a basic workflow;

  1. User opens an application
  2. User creates a file in the application
  3. User Saves the file, with the file name “ShoppingList.xls”
  4. User closes file
  5. User closes application

a week later the same user;

  1. User opens an application
  2. User opens a file called “ShoppingList.xls”
  3. User Saves the file, with the file name “ShoppingList.xls”, and overwrites the existing file
  4. User closes file
  5. User closes application

Now the user wants to retrieve the first shopping list, the problem is they overwrote the file. So straight away we can see that a user may want to use the same file name time and time again. So how do we control this with a PLM system, we have to define attributes that we can track so lets introduce the concept of Version.

A Version is an incremental file change typically an integer so we could add this to the file name as ‘_001’. Lets run the same scenario again;

  1. User opens an application
  2. User creates a file in the application
  3. User Saves the file, with the file name “ShoppingList_001.xls”
  4. User closes file
  5. User closes application

a week later the same user;

  1. User opens an application
  2. User opens a file called “ShoppingList_001.xls”
  3. User Saves the file, with the file name “ShoppingList_002.xls”, and creates a new file.
  4. User closes file
  5. User closes application

So now we have an incremental identifier than allows us to maintain previous content, which means we could open Version ‘_001’ and save it as ‘_003’, this would occur if the user didn’t like the changes in ‘_002’, and wanted to revert back to a previous Version.

This is all well and good but if I made a hundred saves in a day I would have a hundred files on my computer, so this is where the concept of rolling Version can be helpful. We have to decide how many of the previous Versions we want to maintain for example we may want to keep the last five Versions. So if I did one hundred saves I would only have ‘_096’, ‘_097’, ‘_098’, ‘_099’, ‘_100’ Version maintained on the computer, but we want to store these files in the cloud so that they can be accessed from anywhere, so the database and server side storage would maintain the last five rolling Versions.

Revision

So we can revert back to one of five previous saves, but at the end of the day I want to make a backup just in case, or I want to create a copy of the file that I will publish to my friends, while I work on the next chapter. This is where Revision will help us, just like Version, Revision is an incremental identifier also, but is typically an alpha character ‘A’, ‘B’, ‘C’, etc. and is incremented after Release, when a new Release is required. This is the difference between Read/Write and ReadOnly, or more commonly referred to as In-Work and Released.

So lets step through another workflow;

  1. User opens an application
  2. User creates a file in the application
  3. User Saves the file, with the file name “ShoppingList_001_A.xls”
  4. User Saves the file an additional 17 times “ShoppingList_018_A.xls”, and we maintain the previous 5 rolling versions.
  5. User Releases the file “ShoppingList_A.xls”, notice that the version dropped off.
  6. User closes file
  7. User closes application

a week later the same user;

  1. User opens an application
  2. User opens a file called “ShoppingList_A.xls”
  3. User Saves the file, with the file name “ShoppingList_001_B.xls”, and creates a new revision.
  4. User closes file
  5. User closes application

So here we can see that we have a Released file at Revision ‘A’, and an In-Work file at Version ‘_001’ and Revision ‘_B’.

UUID (Universal Unique Identifier)

The last attribute I want to talk about for now is UUID, we can track Version and Revision but we could ahve many users all creating files and sooner or later two or more users will create files with identical names, so what do we do now? We could append a UUID to the file name for example ‘d5cbc39b-fc43-4852-b138-ee5723978dee’ which is a 128-bit integer number used to identify resources. 128-bits is big enough and the generation algorithm is unique enough that if 1,000,000,000 GUID’s per second were generated for 1 year the probability of a duplicate would be only 50%. Or if every human on Earth generated 600,000,000 GUID’s there would only be a 50% probability of a duplicate.

If we were to add this to the file name its going to look pretty ugly, “ShoppingList_d5cbc39b-fc43-4852-b138-ee5723978dee_001_B.xls”. So what other options do we have we could use Date Time stamp for example: 05132021202930 (May 13 2021 20:29:30) which would make our file name a little better “ShoppingList_05132021202930_001_B.xls”.

Additional Attributes

Since we now know that the filename is going to be unique, and we have a mechanism to control previous versions, and if the document is In-Work or Released. We can define additional attributes that we may want to add to the document;

  1. Creation User
  2. Owning User (Last Modifying User)
  3. Creation Date
  4. Modification Date
  5. Check-In / Checked-Out Status
  6. Storage Filename and Path (Which S3 Bucket Were Saving the File in)
  7. Client Side Filename
  8. Status (In-Work / Released / Frozen / Obsolete)

Attributes and Data Types

So we think we have all the attributes we want, all we have to do now is define the data types;

  1. Version (Integer)
  2. Revision (String)
  3. Creation User (String)
  4. Owning User (String)
  5. Creation Date (Date Time)
  6. Modification Date (Date Time)
  7. Check-In / Checked-Out Reservation(String) <CO/CI>
  8. Storage Filename and Path (String)
  9. Client Side Filename (String)
  10. Status (String) <W,R,F,O>

Data Model

dfgd

using System;

namespace SQLite
{
    public class Document_DataModel
    {
        public int Version { get; set; }
        public string Revision { get; set; }
        public string CreationUser { get; set; }
        public string OwningUser { get; set; }
        public DateTime CreationDate { get; set; }
        public DateTime ModificationDate { get; set; }
        public string Reservation { get; set; }
        public string StoragePath { get; set; }
        public string ClientFileName { get; set; }
        public string Status { get; set; }
    }
}