job processor - Vault - PLM integration.

job processor - Vault - PLM integration.

mchi_topsoe
Enthusiast Enthusiast
390 Views
6 Replies
Message 1 of 7

job processor - Vault - PLM integration.

mchi_topsoe
Enthusiast
Enthusiast

We are using the Job Processor to release file to our PLM system (ARAS).

 

It is based on Item State changes. 

ie user set the Item state to "Release to Aras". For an assembly this create one entry in the job queue for each file. 

Job Processor picks jobs accordingly starting Top Down from assembly.
1 job:
- Opening the assembly,
- exports the step file,
- closes the assembly,
- updates the Item state in Vault to "Released",
2 job:
- Opening the part file
- export step
- update the item state to "Released"
- close
-- Etc...

 

Even though it is working, there are a couple of caveats:
Performance: When opening the top assembly, all files are already in memory, and it would be much faster to just travers through the assembly and generate all the files in one go.

Error handling:
- If there is an error when handling a sub part then the main assembly should not be released, everything should go back to previous state.
- The entire batch of step files should not be send to the PLM system, before we know everything is ok.

 

Any suggestions on how to handle this? Ideally we want to release the Main assembly with all its sub-components in one go. But the Item state change seems to be a bad option for this?

 

 

0 Likes
Accepted solutions (1)
391 Views
6 Replies
Replies (6)
Message 2 of 7

Nick_Hall
Collaborator
Collaborator

Hi

 

If you have something that differentiates a top-level assembly from all the other parts/assemblies - such as a property or category - you could have some logic like this:

 

if (identifier = "TopLevel") {
  // Walk the assembly tree
  // Export the STEP files
  // Set the status
}
else {
  // Set the job status to Success
}

 

You could handle all your other logic in the "if" clause

 

It's a bit simplistic, but the approach should work 

 

Hope that helps

Nick

0 Likes
Message 3 of 7

mchi_topsoe
Enthusiast
Enthusiast

Hi Nick

Thanks for your suggestion, but i can not mark individual components differently. there can also be cases where i actually do want to only check in a sub element. 
The approach i will take, is to start by changing the state. Then the user should run a single command. This will then validate that components are released. After this start call the job processor to start on the top assembly only.


Unfortunately this requires two actions for the user. But i can not see how else it can be done.

 

/Michael

 

0 Likes
Message 4 of 7

Markus.Koechl
Autodesk
Autodesk

An alternate option might be implementing an event handler on the lifecycle state change to Released: this handler runs on the success of the top assembly only and submits the job to transfer. It also might add a user input action asking to transfer Yes/No.



Markus Koechl

Solutions Engineer PDM, Autodesk Central Europe
0 Likes
Message 5 of 7

mchi_topsoe
Enthusiast
Enthusiast

 

Thanks Markus.

 

Do you mean a client event handler?

Can the event handler detect the Top-Assembly?

When the user clicks on OK, the files state gets changed, then the event is triggered => we send one single job to the queue?

 

 

 

mchi_topsoe_1-1738660792289.png

 

 

 

 

 

0 Likes
Message 6 of 7

Nick_Hall
Collaborator
Collaborator
Accepted solution

Hi Michael

 

With Markus' idea, the arguments passed to the event handler will contain an array of all the changed state items.

 

You would need to check which one has no parents, which will be the top-level assembly. You might have to use GetItemBOMByItemIdAndDate.

 

Then you add one job to the  queue, passing the Item ID as a parameter.

 

Nick 

 

 

0 Likes
Message 7 of 7

mchi_topsoe
Enthusiast
Enthusiast

@Nick_Hall @Markus.Koechl Thanks for your support:-)

Much appreciated.

/Michael

 

0 Likes