UUID of Document

What do you want to do with that UUID?

Hi  , I want to export UUID in excel for a sack of backup.

Why not just use the document id instead?

 Mathieu Drouin   , I am creating a process in which I'm deleting the extra created documents(cause by failure of PM) from folder.

Process step - 1 : Generating an excel which includes 2 columns, request ID and document ID, So we have which request ID has which Documents extra

Step 2: Moving all those extra documents to a temporary folder by reading the same excel.

step 3: deleting the same temporary folder

But the point is: If somehow we moved a non extra document to temporary folder and it deleted with folder then we can't back it up (whatever the importance of document is).

So we have a plan, we export all the documents by adding them in package and while moving the documents to temporary folder we generate one more excel which have request ID, UUID.

So if this blunder happens (mentioned above), we can import the backup of documents which exported and read the excel which have UUID and restore the documents to their original folders as they were.

UUID is the only thing which will not change on the export and import.

If I go for document ID, it will be useless for us in this case.

What do you suggest ?

Create excel, read excel, move files, temporary folder ..... I am confused! Seriously!

I Appian, I do never manage document by storing them in folders just to delete them. I keep the document ID in process or the database and then such a mishap cannot happen.

But I am open to things I could not imagine.

It should work but it does seems like a convoluted process.

Why not back them up to some external storage (Sharepoint, S3 etc) and simply store external file id in an extra column in the table?

 , I migrated the documents from legacy to cloud, In first time PM fails, so few files migrated and few were not.

later: we fix the PM and migrated all the files.

current scenario: We need to delete those extra files which were first migrated , now they are extra and consuming memory, we need to delete them.

Now: When we create a request , a folder corresponding to that request created,

When I migrated files from legacy, those files get stored in these folders accordingly

Solution: step 1: First of all I want to know which document is extra in which folder and to validate it and present to client I created an excel which have 2 columns (request id and document id).

step 2: By reading the same excel I get the document id, by using that document ID I'm moving the document to a temporary folder so it won't get delete directly (safe side).

step 3: validating all the files moved in temporary folder.

step 4: If validation proves that these files are extra then we are deleting the folder which includes all the extra files.

Point of blunder: on manual validation If we fail to validate correctly then a correct document will be delete, So in order to have a backup I propose the solution in above reply.

Mathieu Drouin It might be a convoluted process but I only have this way to do all this with safe side and storing file in some external storage, I can't say about this.

So you're neck-deep in a mess and trying to salvage the situation. Understood.

May I ask how you did this migration? Appian provides a service to fully migrate on-prem to cloud without loosing anything.

  , I created PM for each table where I'm fetching the data in a batch of 500 and soring them in cloud DB,

For documents, first it's table data migrated (as mentioned above), later migration of the documents started.

Documents stored as a base64 string , So on cloud we decrypt base 64 string and update the document ID of the generated document in Cloud DB.

I was not aware about any service to fully migrate on-prem to cloud without loosing anything, but please tell me the process and steps how to achieve this

And I think you get the solution or safe side I proposed above.

Thank you in advance

For migration, I suggest to contact Appian support or your Appian representative.

I'd suggest also you could use the Document MD5 via the "cryptographic hash functions" plug-in.  The MD5 would always be the same for a given document even cross-environment (and persisting across different exports/imports or even downloads / re-uploads) - the only way 2 documents would have the same md5 is if they're identical.  I used this functinality in the "offload documents to FTP" tool I built last year for my organization, and it went very well.

I'd suggest also you could use the Document MD5 via the "cryptographic hash functions" plug-in.  The MD5 would always be the same for a given document even cross-environment (and persisting across different exports/imports or even downloads / re-uploads) - the only way 2 documents would have the same md5 is if they're identical.  I used this functinality in the "offload documents to FTP" tool I built last year for my organization, and it went very well.