WTDocument primary content delete on Revise?

[khimani_mohiki]

We are storing some Electronic Control Unit configuration files in a WTDocument for version control as they will be physically loaded onto the ECU at the end of the production line. The problem we have at the moment is the file itself has the version in the file name ie 123456_v1.s19 but when the Document is revised it carries the primary content forward, so we end up with a document revision and primary content revision not matching. So the suggestion from the users manging these files is to remove the content after revising, of course this is not ideal as its not guaranteed they will do it and its extra steps to do it.

So Im sure somebody can write me a fancy customisation to do it, but is there a more simple way to acheive the same end result: No primary content on a new Revise?

[jvonzastrow1]

Hi @khimani_mohiki 

To me this is a matter of a good business process.

It is the normal process to use lifecycle in combination with Release management. EX

Revision A is released

Now revision B is needed and revise will create a new version B.1 in state In work. User have to update the wtdocument with the correct content (File) and using release management (Ex Change management) to get it released with the new content. Part of the Release process someone should approve the release. This person will also check if the file is correct.

Remember if the file was removed EX word document, it would be difficult for a user to update it without many extra steps. With DTI users can just open in Word make the chances and save/check-in. 

Do you use, set state, promotions or changes as release process?

Do you have a suptype in use for ECU documents or do you use OOTB wtdocuments?

BR

Johannes

[khimani_mohiki]

Yes that is what we do at the moment, somebody has to check it before it gets released by Change Notice, but its not foolproof and creates extra work for somebody to check it. Also sometimes the person making the change is also the person able to approve the change, so its easy to get missed. In general we are trying to move away from having to check and cross reference numbers manually. I understand the system is working as expected because you normally wouldnt want to remove primary content for something like a CAD file or a Word document, but in this case there is no way to connect and authoring application for these types of files.

[mmeadows-3]

FYI: When we revise a content holder in Windchill, the last iteration of the previous revision (e.g. A.3) and the first iteration of the latest revision (B.1) point to the same content file.  So when you describe removing the content file from B.1, what you really mean is to break the association to the existing content file.  If we actually removed the content file associated with B.1, we would also remove the content file for A.3.

I agree with @jvonzastrow1 that this is a business process issue.  We do not want to minimize/eliminate checking.  That just lets more errors thru.  We do not want to customize PTC's revise code either.  It won't prevent someone from promoting/releasing a new revision that doesn't have associated content.

Instead, look into automating release validation with business rules checks.  This check can be automated.  If this Document subtype is being released thru a promotion request or change notice, confirm it is not the first iteration of the revision (e.g. must be B.2 or higher) AND confirm the file name of the latest iteration does not match the file name of the first iteration.

You can write the customization using PTC's Business Rules or use a Windchill extension like Object Validator.

[khimani_mohiki]

I like this suggestion:

"Instead, look into automating release validation with business rules checks.  This check can be automated.  If this Document subtype is being released thru a promotion request or change notice, confirm it is not the first iteration of the revision (e.g. must be B.2 or higher) AND confirm the file name of the latest iteration does not match the file name of the first iteration."

Seems like it meets the business need and removes additional manual checking, I will have a look into it, thanks!

[jvonzastrow1]

Hi @khimani_mohiki 

During check-in of wtdocuments users are asked to upload file. Perhaps this can be set by preference to select "Upload file" as default. 

BTW. It is never a good practice to approve your own work. Why then approve at all? 

[d_graham]

Khimani,

One easy and bombproof way to do this is to use a listener. It will take the users out of the equation.

When a WTDoc is Revised the listener will fire and run code to delete the primary.  All automatic and bombproof.

The event to key off is the PersistenceManagerEvent/POST_STORE listener.

The listener would automatically detect when an objects is STORED (not saved or modified but stored meaning only the first time that specific object is persisted to the dB) . When that happens the code in the listened would check if the stored object is a WTDocument, and if it's the first iteration of that version.  If it is, the code then deletes the primary content (and attachments if desired).

Simple, reliable and no user actions involved.

As mention by @mmeadows-3 after revise the same file in the vault will be linked to the latest and second latest iterations of the master (A.5 and B.1 for example) so simply deleting the linkage to B.1 is all you need to do.

If your workflows use synch robots then you have used a listener.  However, if you write your own the door is open to do pretty much anything.

If you want help with this drop me an email.

David