Hi,
I've configured publish rule xml to trigger publish of SolidWorks assembly as .step in Attachments for the EPMDoc when change of lifecycle state to "Approved" occurs (plus a couple more defining attributes), ie. "unknown-source" as the key.
When either Set state or Promotion request on the EPMDoc is used to set the state to "Approved" the publish starts, but in Job monitor I see the associated WTPart number, not the EPMDoc number for the assembly. step-file is found in EPMDoc Attachments as expected.
When publishing .step manually through New representation in Job Monitor there's the EPMDoc number.
Why is this?
11.1 M020 CPS20
Solved! Go to Solution.
Hi @HJ1
it is normal that the WTPart can be seen in the Job Monitor
The WTPart is something as envelop with information and one of them is CAD Document.
There are many situations when WTPart is send to publish, for example if visualization does not exists and user clicks on the empty default representation on the detail page of WTPart.
PetrH
Hi @HJ1
A General reason is that the visualization is "shared" between EPMDocument and WTPart.
If the EPMDocument is linked correctly with WTPart the visualization is stored on the WTPart even though it is shown on the EPMDocument.
If you start publish job manually from EPMDocument, the EPMDocument is shown in the Job monitor.
If you start publish job manually from WTPart, the WTPart is shown in the Job monitor.
If the job is started automatically from some workflows the WTPart is also collected to republish it. this is usually unknown source for publishing.
That is a reason why you can see WTParts in the Job monitor.
PetrH
Hi!
Utterly confusing 😁
And troubling, "linked correctly with WTPart"? They're always with Owner link. We've published 3D visualization forever at checkin, on state change whether Set state, Promotion Request, Change Notice audit and never, NEVER, there's WTParts in Job Monitor, only EPMDoc numbers.
I know, I'm the guy rebooting worker when Failed hits the screen 😂
Having said that, a few occasions I have noticed WTParts. I don't know why, but I suspect it's related to user initiating from WTPart. Now I'm looking at automating .step publish to certain Approved 3D items and now WTParts popped up when testing publish on state change.
Hi @HJ1
Correctly connected means that 3D model and WTPart are checkined together or the build WTPart process was initialized manually from CADModel.
Sometimes someone create just owner link with WTPart that only WTPart is checked out-in but this connection do not populate attributes to the WTPart
Your thoughts are correct. If the processes do not contains WTParts as a part of change, then it should not be in the Job Monitor.
If user initial publishing on the WTPart then it is surly in the Job Monitor.
Also the Job Monitor shows WTPart if they are part of change process where the visualization is done automatically.
I usually add a workflow robot to send objects to a publish queue if the process is approved and goes to the end of process.
check an another thread where this is discussed >
Hope this can help
PetrH
Hi,
ok, majority of checkins is done as you describe, CAD and WTPart together thus CAD 'driving' the WTPart & structure. Also, usually all, WTParts, 3D and drawings, are collected to the same Promotion Request. But, no WTParts in Job Monitor.
Maybe this is something I can live with as publishing .step seemed to work and it's not that often so it does not confuse in Job Monitor too much.
I'll have a look at the link, thanks!
Hi @HJ1
it is normal that the WTPart can be seen in the Job Monitor
The WTPart is something as envelop with information and one of them is CAD Document.
There are many situations when WTPart is send to publish, for example if visualization does not exists and user clicks on the empty default representation on the detail page of WTPart.
PetrH