Getting around the limitations of Gatekeeper

[gspencer]

Greetings Admins -

So, it goes without saying that Gatekeeper is extremely limited in its capability. Wht PTC didn't design the filter to look for certain check types, rather than a cumulative total amount is beyond me...perhaps some of you out there have opinions on the subject?

In spite of these limitations, my company is moving forward with using Gatekeeper to allow "0" errors.

Here are few of the items I hoping you folks can provide some guidance on -

Scenario: We have the “checks.mch” file configured where we have 5 checks identified as “Errors”. These 5 errors are the “critical” stuff like “FAILED_COMPONENTS” that must not be allowed into Windchill for models being “Released” under any circumstances. The other part of this scenario is we have Gatekeeper configured to allow “0” errors.

1^st Question: If our methodology is that want to allow “In Work” models to be checked in under any circumstance, but truly have “0” errors when set to “Released”, how might that be done?

The idea is to allow looser standards at In Work, but more rigid ones at Released. Since the State change from In Work to Released is a Windchill function, not a Creo function, I am having some trouble getting my head around how we can accomplish this? One thought I had was to make it part of the Change process, where there is an associated Change Task to “fix” all errors before it goes to Released….thoughts, comments??

2^nd Question: My company is insisting on of an “override” policy. The policy temporarily allow “Errors” to get into Windchill at the Released state. The process would be defined so that there would be tracking for these override scenarios, so they are fixed ASAP, rather than just forgotten about. 

So, my idea on this would be to add a condition parameter into the Creo models, where the value of the parameter would determine whether Gatekeeper checks or ignores the model…something like a “CHECK/NOCHECK” value…thoughts, comments??

3^rd Question: The setconf.mcc file allows us to have different “check configurations” based on how a model is classified (OOTB- Heavy, Medium, Light). Based on the scenario noted above, I am wondering how this might help us to get to where we want to be? I suppose we could have “In Work” models look at a set of configs where all checks are “warnings”, which would get us around Gatekeeper, but for “Released” models, we are back to same question that comes up with Question 2….need some guidance here.

4^th Question: Legacy models: Lastly, I think it bears mentioning that out intent with legacy data would be to “NOCHECK” them unless they become part of the Change (revised back to In Work). Since this requires a condition.mcc to ignore “Released” models, how does that play into the above scenario?

My appreciate in advance for any feedback you are willing to provide...

Gary

[osenbore]

Hi,

I just noticed your question now.  If you still need answers:

Question 1:  This would be a fantastic place to use the Modelcheck condition.mcc file to check for the Windchill parameters.  So you could have a logic like: If Parameter "State" is set to In Work, use Check file 1, If Parameter "State" is set to Released, use Check file 2.  Then in Check file 1, you have the 5 checks as errors, and in Check file 2, you can downgrade the same 5 checks to Warnings (so no errors pop up - as long as everyone else in the company agrees to check for Warnings in Released Models and fix them)

Question 2: The answer to question 1 would help here.  Also, doing a condition.mcc logic like If Parameter "Nocheck" exists, skip checking would also work.

Question 3:See question 2 above.

Question 4:I think this is also answered by question 1.  As long as Released legacy models have a Parameter called Released, you could set Modelcheck condition.mcc to If Parameter "State" is set to Released, use Check file 2 (in Check file 2, you can downgrade the same 5 checks to Warnings, so no errors pop up, and Legacy models can slide through Gatekeeper).  Alternatively, you could do If Date Created is less than May 1, 1990, NOCHECK.  This will force Modelcheck to skip checking models that were started before a specific date (if you can classify your legacy models by date.)

Hope this helps.  Dont hesitate to send me a message if you have more questions.

[BenLoosli]

The conditions file check for state will not work because ALL files being submitted to ModelCheck are actually at the InWork state coming from Creo.

What you can do is set up a restricted parameter, ModCheck or something, that is by default set to InWork and use the condition file to check for its value. Whenever the file is checked-in, ModelCheck would run the InWork checks. When a designer is ready to submit a file for release, he can manually set the restricted parameter to Release, which would trigger the more extensive checks and prevent the file from being checked in if it fails any. The key to making ModelCheck work is to get your designers to check the results files and correct the errors that it detects. An additional check would be in the release workflow to add a check to see that file being promoted has the Release flag set for your parameter. This would indicate that the file has been run through ModelCheck with the Release conditions and they all passed.