Prohibit CAD Document publish in state Under Review

[HJ1]

Hi,

Is there a way to prohibit publish of CAD Documents entirely based on a specific life cycle state, in this case "Under Review"? It does not add any value for the publish to run because of Promotion process.

I've tried to work around with this in the publishrules.xml / Visualization Configuration Administration, but this is not the solution because it's not that straight forward with the other state values:

<not>
<attribute name="epmdoc_lifeCycleState" value="Under Review"/>
</not>

Just simply tell somewhere "if state is Under Review do not trigger publish", but where?

[TomU]

Use one of the filter methods and a Java file to analyze state and determine whether to proceed or not.

publish.positioningassembly.filtermethod=ext.TMPublishHelper/shouldPublishEPMDoc

Here is an example that blocks publishing for certain file types:

package ext;

import wt.epm.EPMDocument;
import wt.epm.EPMDocumentType;
import wt.epm.EPMAuthoringAppType;
import wt.fc.Persistable;
import wt.wvs.WVSLogger;

public class TMPublishHelper {

	private static final WVSLogger logger = WVSLogger.getLogger(TMPublishHelper.class, WVSLogger.PUBLISH_GROUP);
	// Log Levels
	// logger.fatal("Fatal message");
	// logger.error("Error message");
	// logger.warn("Warn message");
	// logger.info("Info message");
	// logger.debug("Debug message");
	// logger.trace("Trace message");
	
	public static Boolean shouldPublishEPMDoc(EPMDocument d) {
		// This method will never get called by Windchill if the one below it (getPosAsminfo) is being used.  The stuff below is just an example...
		
		boolean shouldPublishFlag = true;
		String cadName = d.getCADName();
		logger.debug(cadName + " is ready to publish.");
		if (cadName.endsWith(".mfg") || cadName.endsWith("_harn.prt") || cadName.endsWith ("_mfg.asm") || cadName.endsWith ( "_flat.asm") || cadName.endsWith (".idr")) {
			logger.debug(cadName + ": will not be published due to file type.");
			shouldPublishFlag = false;
		}
		if (shouldPublishFlag) {
			logger.debug(" **************** Succedded...!!!");
		}
		return Boolean.valueOf(shouldPublishFlag);
	}

[TomU]

This would be the better one to use.  The previously mentioned filter is specific to assemblies.

publish.service.filterpublishmethod=

We use this filter and some corresponding Java code to block 'under review' re-publishing for everything except the drawing.  (We want that to republish so we can watermark 'under review' on it.)

if (epm.getLifeCycleState().equals(State.UNDERREVIEW)

... do stuff ...

[HelesicPetr]

Hello @HJ1 

Publish rules can cover your needs. You need to just define condition where publish action is not used.

example

	<condition name="do_not_publish">
			<and>
				<attribute name="epmdoc_lifeCycleState" value="Under Review"/>
			</and>
	</condition>
	
		<if condition="do_not_publish">
		</if>
		
		<publish additional-files="standard_files" on="checkin"/>
		<publish additional-files="standard_files" on="create-representation"/>
		<publish additional-files="standard_files" on="schedule" />
		<publish additional-files="standard_files" on="unknown-source" />

PetrH

[HJ1]

Hi @HelesicPetr !

Sorry, I'm useless with these... which part is it that leaves out publish entirely, in your example you've got the "<publish..." lines outside the if-clause, that it?

<if condition="do_not_publish">
		</if

Because, I tested with entering just that empty if clause (and the condition, of course) and first it seemed to work, but after further editing the rule it didn't.. not sure now if I got your idea right  🙄     It is something like this I'm looking for and tested, but never got the syntax right.

[HelesicPetr · Accepted solution]

Hi @HJ1 

Yes the publish actions are outside of if condition

because if the condition is not met it will publish all other situations. 

You can also combinate it with other conditions. 

The best would be to share the PublishRule xml to see what could be wrong. 

 Be careful to combinate more conditions together. The sequence of conditions is very important .

If first condition is met the second is not used anymore for one object.

It happened to me many times.  

My full example> (if conditions are not met it will publish standard_files configuration)

<?xml version="1.0"?>
<rules evaluate-rules-on-republish="true"
	xsi:schemaLocation="http://www.ptc.com PublishRulesSchema.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ptc.com">
	<authoring-application name="PROE"> 
		<additional-files name="standard_files">
			<!-- only default='true' files will be generated at this time -->
			<file output-prefix="step" default="false" type="step" display-label="STEP"/>
			<file output-prefix="iges" default="false" type="iges" display-label="IGES"/>
			<file output-prefix="dxf" default="false" type="dxf" display-label="DXF"/>
			<file output-prefix="cgm" default="false" type="cgm" display-label="CGM"/>
			<file output-prefix="pdf" default="false" type="pdf" display-label="pdf"/> 
		</additional-files>		

		<additional-files name="released_drawing">
			<!-- only default='true' files will be generated at this time -->
			<file output-prefix="dxf" default="true" type="dxf" display-label="DXF"/>
			<file output-prefix="pdf" default="true" type="pdf" display-label="pdf"/> 
		</additional-files>

		<condition name="do_not_publish">
			<and>
				<attribute name="epmdoc_lifeCycleState" value="Under Review"/>
			</and>
	</condition>
			
	<condition name="is_released_drawing">
			<and>
				<attribute name="epmdoc_CADName" regex=".*\.drw" />
				<or>
					<attribute name="epmdoc_lifeCycleState" value="Released"/>
					<attribute name="epmdoc_lifeCycleState" value="Uvolněno"/>
					<attribute name="epmdoc_lifeCycleState" value="Schvaleno"/>
				</or>
			</and>
	</condition>

		<if condition="do_not_publish">
		</if>
		
		<if condition="is_released_drawing">
			<publish on="checkin" display-label="Released Drawing"  additional-files="released_drawing"/>
		    <publish on="create-representation" display-label="Released Drawing" additional-files="released_drawing" />
		    <publish on="schedule" display-label="Released Drawing"  additional-files="released_drawing"/>
		    <publish on="unknown-source" display-label="Released Drawing"  additional-files="released_drawing"/>
		</if>
		
		<publish additional-files="standard_files" on="checkin"/>
		<publish additional-files="standard_files" on="create-representation"/>
		<publish additional-files="standard_files" on="schedule" />
		<publish additional-files="standard_files" on="unknown-source" />
	</authoring-application> 
</rules>

PetrH

[HJ1]

Hi,

thanks for the input again. Our current rule may require a bit of cleaning up before I dare to make it public  😅  It's been modified a couple of times by adding conditions and yes, this may contribute to what you pointed out that the sequence of things needs to be checked thoroughly even though that part looks ok to me.

Another thing occurred to me while following up publish with the edited rule to leave out "Under Review". As an example:

- a drawing is checked in say at 8.30. State is "In Work". 'Checkin creates a publish job' in the queue.

- the drawing is added to Promotion request at 8.38, thus state is changed to "Under Review"

- meanwhile publish queue proceeds and it's this drawing's turn. Job starts at 8.45. The published pdf shows "Under Review".

So... based on the above, looks like the publish job checks the data at the time of job start, not when it entered the queue? If so, the purpose to reduce not needed publish jobs is met (leave out state change "Under Review" as trigger), but the result is confusing to users. Sometimes there's "In Work", sometimes "Under Review".

@TomU , does your solution answer this?

You may also ask is there something wrong with our workers processing stuff such a long time... or, actually the question is, why is it sent to promotion if it's not with the latest attachments  😄 

[HelesicPetr]

Hi @HJ1

The Publish Rules are generally checked before the object goes to the publishQueueLMH 

There could be a gap between the checking rule and real publishing job.

If the lifecycle state is changed before publishing and regeneration is set in RCP editor for visualization then the state will be different.

PetrH

[TomU]

@HJ1,

It doesn't matter if the publishing is prevented (or allowed) by the publish rules or by one of the filter methods, the end result is still driven by what Creo 'sees' when it loads the files up to publish them.  If the lifecycle state is displayed on the drawing (not recommended), then Creo is going to display that value from Windchill at the time the files are opened in Creo by the CAD worker.  There is no way for Creo to show what the state used to be back when the publish event was first submitted.

[HJ1]

Ok, thanks Petr and Tom, makes sense of course.

Currently the rule seems to do the job, probably could still finetune, but "don't touch it if it works" for now  😎