I'm trying to create a query for use in a workflow condition task.
It needs to branch when a item revision related to one of the workflow targets is also in the workflow targets.
I can already query the item relation, but i'm having trouble getting the targets relation.
How do I determine whether a item revision is related to the workflow targets?
Already found a possible solution here, it query's the EPMTask attachments, but the query builder class selection tells me the property is depreciated.
Also can't find the specified Release Bulletin 11.1
Solved! Go to Solution.
Using the attachments variable length array has changed in Teamcenter 11 to using types of ImanRelation.
So target attachments are now related to the task via the Fnd0EPMTarget relation.
A more complete description of this is in the Workflow Designer Guide section "Migrating Workflow Attachments".
It's in GTAC here for 11.5, but applies to earlier 11 versions.
Thanks, got the workflow relation!
The query now returns the item revision when it's in a workflow.
But, this returns the item revision also when it's in the targets of any other workflow, not necessarily the workflow that initiated the query.
as the query attribute with "IS_NOT_NULL".
Is it possible to only return the workflow that initiates the query?
You can probably get close. It depends on if you can have multiple workflows active at the same time that reference your object.
If you query for a specific task name rather than is not null then it will filter the candidates down to a single type of workflow.
You will also probably need to add some criteria to check the state of the task.
For example if you check for state_value = 4 on the EPMTask then this will only match tasks that have started.
This filters out the workflows that have your object as a target, and have completed, or been aborted etc.
If you can't support your use case with a query then you may be able to use some other techniques; maybe some incantation of EPM-invoke-system-rule with some scripting may work for you.
Thanks, this works well!
Using the state_value rules out other workflows (for now) cause we don't use multiple running workflows at the same time.