I am trying to set up a workflow whereby the user could attach more than one Item Revision as targets and get a xml file with info from its BOM (in case it has one) and the files within the BOMLines contained in that BOM. I would like to get separate xml files and file folders for each of the Item Revisions sent to that workflow.
In my first attempt I used the PIE-export-to-plmxmlfile handler (-context=ConfiguredDataFilesExportDefault | -attach=target | -revrule=Precise Only) and realized that only one xml file was created containing all the info I would want as separate xml files and a single folder contained all the exported files. It works fine when sending a single Item Revision to the workflow, but my goal would be to be able to send multiple Item Revisions.
To that end, I have tried to define this workflow as a subprocess of another one where using the EMP-create-sub-process handler (-template=previousWFname | -from_attach=Target | -to_attch=Target | -multiple_processes) I am able to send the Item Revisions separatedly to the workflow doing the export. In this case I get separate xml files for each Item Revision, but I am not getting any folder with the files I need to export out of TC.
I see this in tcserver*.syslog:
INFO - 2019/01/10-12:51:45.500 UTC - TCRSPRUEBA.67370.01.anartz.00497 - PLMXML Export filename is C:\temp\001863_00-00;1-Conjunto Prueba Tracelink del Tracelink:1.plmxml - Teamcenter.Workflow.epm at d:\workdir\tc115w0616_64\src\core\epm\foreign_handlers\pie_workflow_handlers.cxx(281)
ERROR - 2019/01/10-12:51:46.000 UTC - TCRSPRUEBA.67370.01.anartz.00497 - 23: Fin del archivo en lectura. - FSC_Download error: 23 CURLE_WRITE_ERROR: Error saving data (locally) received on the network connection. - Teamcenter.Organization.sa at d:\workdir\tc115w0616_64\src\core\sa\fscinterface.cxx(1621)
And this in tcserver*.fscproxylog:
WARNING: FSCClientAgent.download(): http://TCRSPRUEBA:4544/tc/fms/-1911185732/mygroup/FSC_TCRSPRUEBA_Administrador GET failed: 23 CURLE_WRITE_ERROR: Error saving data (locally) received on the network connection.
Checking the first line I pasted from syslog I noticed that it is trying to wirte the plmxmlfile with a ':' character in it, something Windows does not allow and that is not entirely true, as the file is being written with a '_' in the place the ':' is supposed to be. My guess is that it is trying to create a folder with the same name, containing the ':', and that is not being able to and, therefore, the files cannot be exported anywhere.
Looking the documentation about the EPM-create-sub-process handler I have observed this:
If the workflow process name is not given, and the -multiple_processes argument is used, the name assigned is in the format of subprocesstargetdisplayname - item-name : count . In this case, that would be item1/A-wheel:1 , item2/B-axle:2 , item3/A-bearing:3 . In the case where the parent had no targets, the name is parentprocess:1 .
So I am fearing that my reasoning has been faulty from the beginning and I am not going to be able to achieve what I am looking for. My hope is that as the *.plmxml file has been written on disk replacing the ':' for a '_' there might be a way to achieve that replacement in the folder name as well, but I do not know how I could set that up.
Could any of you provide any help or advice, please? Sorry for the long post, I have tried it to be as brief as possible.
I can replicate your findings too. Maybe raise a call with GTAC to see if there is a solution if no-one from here can help.
The only way I can think of is very complex... Command line PLMXML_Export delivers what you want....
plmxml_export -u= -p= -g= -item=000101 -rev=00 -transfermode=ConfiguredDataFilesExportDefault -xml_file=000101_00.xml
plmxml_export -u= -p= -g= -item=000102 -rev=00 -transfermode=ConfiguredDataFilesExportDefault -xml_file=000102_00.xml
Like I said, a very complex workaround!
I had an xsl doing something similar. Below is a quick stab at what you would need. I havent tested it, but I'm pretty confident its right:
<?xml version="1.0" ?>
<xsl:output method="text" omit-xml-declaration="yes" indent="no"/>
<!-- We want to build a command line that looks like
plmxml_export -u= -p= -g= -item=000101 -rev=00 -transfermode=ConfiguredDataFilesExportDefault -xml_file=000101_00.xml -->
<xsl:text>plmxml_export -u= -p= -g= -item=</xsl:text>
<!-- Outputs the Item ID -->
<xsl:variable name="ID" select ="..//plm:UserValue[@title='item_id']/@value"/>
<!-- Outputs the Revision No -->
<xsl:variable name="REV" select ="..//plm:UserValue[@title='item_revision_id']/@value"/>
Thank you Richard!! I opened an IR earlier this morning and we'll have to wait for news from that side too, but the workaround you propose seems promising!! I'll give it a go monday morning and I'll let you know what I get.
Attached is a working xsl file.
You need a transfermode which has a Closure rule and Property Set which looks something like:
The workflow handler arguments:
The command to upload the xsl and attach it to the transfermode:
plmxml_tm_edit_xsl -u=infodba -p=infodba -g=dba -transfermode=IE_Revision_Export_PLMXML -action=attach -xsl_file=IE_Revision_Export_PLMXML.xsl
The result is a plmxml.bat file which looks like:
You just need a bat file to run the exported plmxml.bat file now and to call it from the workflow.
Note - after attaching the xsl to the transfermode you may need to restart your client for the changes to take effect. Also, I have used infodba as its a Test system. I wouldnt normally use this user!
Richard, thanks so much for taking the time and effort in helping me out with this. It's been a tough monday and I just had the chance to take a breather and try your solution. I am sorry to report that I am not being able to attach the *.xsl file to the transfermode using the command you mention in your post...
I attach an image of the error message.
I was copy/pasting the command line directly from your post and it kept failing. I tried to type it from scratch and succeeded!! I guess it was related to the '-' character, if I am not wrong there are multiple dash-like characters that can be easily mistaken one for another.
Thanks a lot Rich, I will go on with the next steps over the next few days. I will keep you posted ;)