nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow Modeler - Custom Instantiation Screen and list of files

anisha

In the old workflow files (.wft), one could get the list of files attached to the job by accessing __ELEM__('iw_file').

Does anyone know a way to get the same in workflow modeller instantiation screen?

Find more posts tagged with

Comments

pdasarat

Can you brief your requirement, as of the new modeller you cannot access this element, but brief your requirement with the new modeller to help you.

Pradeep

miletwo

Can you brief your requirement, as of the new modeller you cannot access this element, but brief your requirement with the new modeller to help you.

Pradeep

Am I the only one who has absolutely no clue what this means? I'd like to be able to help, but I'm totally lost.

J.Anderson

Adam Stoller

Can you brief your requirement, as of the new modeller you cannot access this element, but brief your requirement with the new modeller to help you.
Am I the only one who has absolutely no clue what this means? I'd like to be able to help, but I'm totally lost.

J.Anderson

I believe the English translation would be something like:[indent]Can you explain your requirements more fully? I [pdasarat] do not believe that you can access this element [pre-selected files] within the new Workflow Modeller templates, but if you can explain your requirements in more detail perhaps someone can help you figure out how to satisfy them within the new Workflow Modeller[/indent]That's my guess ...

As I haven't had much opportunity yet to play with the WFM, I can't tell you whether it's easy to get at this information or not -- but I have to assume that it can be gotten since the information is used for driving things like prompts for per-file comments during instantiation.

Of course one can always access the list of files from within an externaltask or cgitask - but I'm assuming that the requirement mandates conditional coding prior to / during instantiation and not after instantiation ...

anisha

I think Ghoti has summarized it nicely.

I need to check if any of the user selected files are already attached to an existing active job(s) before letting the user initiate a new job.

New workflow modeller provides macro variables where file path is available. Unfortunately these variables are not available on the instantiaion screen [Ref: page 60 of wfm guide].

WFM lets us specify if file comments are required in the workflow properties section. I think behind the scenes java modules are translating the property to display the list of files and I still could not figure a way to obtain the list of files in the instantiation screen.

Adam Stoller

I think Ghoti has summarized it nicely.

I need to check if any of the user selected files are already attached to an existing active job(s) before letting the user initiate a new job.

New workflow modeller provides macro variables where file path is available. Unfortunately these variables are not available on the instantiaion screen [Ref: page 60 of wfm guide].

WFM lets us specify if file comments are required in the workflow properties section. I think behind the scenes java modules are translating the property to display the list of files and I still could not figure a way to obtain the list of files in the instantiation screen.

Worse comes to worst - you can start the workflow off with a cgitask that performs the check of the files and makes sure they're not associated with more than one job (since they'll be associated with the current job) - and if they are, display information about it and then either let the user "fix things" or just tell them and let them transition the job so that it ends gracefully (or something along those lines)

pdasarat

Can you brief your requirement, as of the new modeller you cannot access this element, but brief your requirement with the new modeller to help you.

Pradeep

I remember typing what Ghoti has typed, may be something got off my head while I was replying, but anyways as of know I don't think we can access the file list in the instantiation screen.

Pradeep

FurnaceFace

TS 6.7.1
Solaris 9i

Has anyone found a way to access the file list from the instantiation screen yet using WFM?

The reason I ask this question is because I have a workflow that is used to edit DCRs. The problem is that if there are no DCRs selected, ALL modified DCRs in the current directory and subdirectories are attached to the workflow. I need to know if any DCRs have been selected before the instantiation screen comes up.

As Anisha said, "In the old workflow files (.wft), one could get the list of files attached to the job by accessing __ELEM__('iw_file')."

Surely there must be an equivalent - Why would IW remove functionality that has proven useful in the past?

I believe that the instantiation screen comes up before any external task can be called so I ruled that option out.

Recommendations?
Thanks,
/FF

Adam Stoller

Has anyone found a way to access the file list from the instantiation screen yet using WFM?
[...]
As Anisha said, "In the old workflow files (.wft), one could get the list of files attached to the job by accessing __ELEM__('iw_file')."

Surely there must be an equivalent - Why would IW remove functionality that has proven useful in the past?
[...]

I think you're making a somewhat erroneous assumption - it's not necessarily that IWOV removed functionality, but more that they might not have ensured that all useful functionality was re-implemented when they brought in the WFM (which I believe was, at least in part, OEM'd).

The __ELEM__(), __VALUE__(), __TAG__(), and __INSERT__(), functions were all developed in Perl. The new system does not use Perl - thus functions like that would have to be re-implemented.

In a similar though slightly different way - the concept of storing the information that used to be accessed through Perl and/or CGI form variables (e.g.: iw_file) in a manner that can be accessed via JavaScript also needs to be re-implemented - and while I think they managed to get a number of such items, this appears to be a notable exception.

Hopefully this will be fixed (or the solution explained / documented) in the near future.

RajatChopra

Has anyone found a way to access the file list from the instantiation screen yet using WFM?

The reason I ask this question is because I have a workflow that is used to edit DCRs. The problem is that if there are no DCRs selected, ALL modified DCRs in the current directory and subdirectories are attached to the workflow. I need to know if any DCRs have been selected before the instantiation screen comes up.

There was a webcast today on WFM in 6.7.1 SP1 and its functionalities. The presenter created a workflow in which he created a Pre-Processor class for attaching files to the workflow. Though the files that he added were hardcoded into the class. I tried asking the same question, what we are discussing here, though he mis-understood it.

Essentially, i believe that you might have to write a class that can use the in-built framework for WFM. Not aware of all the API calls that exist to help you achieve your goal.

The webcast should be available on DEVNET soon enough. I'll try to post the link here when i get the email.....

FurnaceFace

I think you're making a somewhat erroneous assumption - it's not necessarily that IWOV removed functionality, but more that they might not have ensured that all useful functionality was re-implemented when they brought in the WFM (which I believe was, at least in part, OEM'd).

Not to mince words but when you say "re-implement" does that not mean that something has to be implemented that used to be there? To me that would indicate that functionality was removed when they created WFM (though still intact for the older *.wft format). I'm not saying they removed it permanently but they did not tell developers how they exposed it or how to access it (from what I have read, it is not formally documented)

That small point aside I believe my co-worker and I have found a possible solution to this issue. We viewed the source code on the "select workflow" screen once you select "Action -> New Job" to see if there was any information in there that we could use.

In the javascript for this screen, there is a hidden input field that is created if a user selects files or folders. In this example, I selected a folder called "internet" and then selected "new job"

In the source code, the following hidden input and value is created.

If the user did not select any files or folder, this input field will not appear in the source.

How can I put this to use you ask? Simple. In your custom_instantiation.cfg file, you insert some javascript into a "onforminit" event that allows you to loop through the variables on the parent document (which happens to be the workflow selection screen). If you find an input type that has a name == to "iw_model_files" then you know that the user selected specific files. If you do not find that value, you know they have not selected any files.

Yes it is a bit of a workaround and probably not fully supported because it could change for SP1 BUT it is all that we have to go on at the moment for WFM 1.0.0.0 - hope this helps.

Here is some rough javascript code for the custom_instantiation.cfg screen that allows you to check for the hidden input field. (you can change the 15 number to find the max # of elements on the page instead - it's been a busy morning here so I haven't had too much time to clean things up)

for(i=0; i<=15; i++){
if((parent.document.getElementsByTagName('input').name == "iw_model_files") && (parent.document.getElementsByTagName('input').value != "null")){

}
}

I know that some of you will say that this is not supported or the proper way of doing it but if you can find a better way using WFM 1.0.0.0 , I'm more than happy to listen.

Thanks,
/FF

Adam Stoller

A comment or two - but mostly fixing formatting so others can see what was written ...

Not to mince words but when you say "re-implement" does that not mean that something has to be implemented that used to be there? To me that would indicate that functionality was removed when they created WFM (though still intact for the older *.wft format). I'm not saying they removed it permanently but they did not tell developers how they exposed it or how to access it (from what I have read, it is not formally documented)

"re-implement" as in they had certain functionality implemented within the "old" UI that appears to need to be implemented in the "new" UI - the two UIs are vastly different so it's a case of re-implementing, not restoring - which would imply that it was there in the new UI and removed.

That small point aside I believe my co-worker and I have found a possible solution to this issue. We viewed the source code on the "select workflow" screen once you select "Action -> New Job" to see if there was any information in there that we could use.

In the javascript for this screen, there is a hidden input field that is created if a user selects files or folders. In this example, I selected a folder called "internet" and then selected "new job"

In the source code, the following hidden input and value is created.[html][/html]If the user did not select any files or folder, this input field will not appear in the source.

How can I put this to use you ask? Simple. In your custom_instantiation.cfg file, you insert some javascript into a "onforminit" event that allows you to loop through the variables on the parent document (which happens to be the workflow selection screen). If you find an input type that has a name == to "iw_model_files" then you know that the user selected specific files. If you do not find that value, you know they have not selected any files.

Yes it is a bit of a workaround and probably not fully supported because it could change for SP1 BUT it is all that we have to go on at the moment for WFM 1.0.0.0 - hope this helps.

Here is some rough javascript code for the custom_instantiation.cfg screen that allows you to check for the hidden input field. (you can change the 15 number to find the max # of elements on the page instead - it's been a busy morning here so I haven't had too much time to clean things up)[html]for(i=0; i<=15; i++){
if((parent.document.getElementsByTagName('input').name == "iw_model_files") && (parent.document.getElementsByTagName('input').value != "null")){

}
}[/html]I know that some of you will say that this is not supported or the proper way of doing it but if you can find a better way using WFM 1.0.0.0 , I'm more than happy to listen.

Thanks,
/FF

Good detective work - a shame you (or any of us) had to go through it.

FurnaceFace

A comment or two - but mostly fixing formatting so others can see what was written ... "re-implement" as in they had certain functionality implemented within the "old" UI that appears to need to be implemented in the "new" UI - the two UIs are vastly different so it's a case of re-implementing, not restoring - which would imply that it was there in the new UI and removed.Good detective work - a shame you (or any of us) had to go through it.

Agreed Ghoti Smiley Happy

Thanks!

I also want to mention that my co-worker found out that the parent document is not the workflow selection screen but rather the top layer of the form/screen that is created by the custom_instantiation.cfg file. The view source always has a hidden input named "iw_model_files" and if there are no files/folders selected, the value is "null".

Hope this helps,
/FF

anisha

sorry, been a while since I visited this post. I should have posted the feedback I got from Iwov support on this; It's inline with what FurnaceFace suggested.

*****************************
response from Iwov support:
According to engineering, we add a few request parameters:
iw_model_files -> will contain comma separated area relative paths
iw_model_branch -> vpath of the branch from where the workflow is
instantiated iw_model_areavpath -> vpath of the workarea from where the
workflow is instantiated

NOTE: These parameters will be removed from SP1 onwards, as an
easier/cleaner way will be provided.
*************************************

ReggieRWalker

sorry, been a while since I visited this post. I should have posted the feedback I got from Iwov support on this; It's inline with what FurnaceFace suggested.

*****************************
response from Iwov support:
According to engineering, we add a few request parameters:
iw_model_files -> will contain comma separated area relative paths
iw_model_branch -> vpath of the branch from where the workflow is
instantiated iw_model_areavpath -> vpath of the workarea from where the
workflow is instantiated

NOTE: These parameters will be removed from SP1 onwards, as an
easier/cleaner way will be provided.
*************************************

Has the "easier/cleaner" way been revealed?

ConcatenateByGroup.zip

justanickname

Has the "easier/cleaner" way been revealed?

I did not hear about it.

But if you look at the code behind the workflow instantiation screen, I've seen that they've changed the parameters names..... but you can easilly guest the mapping between the old parameters and the new ones Smiley Happy

...

sample_Notworking.txt

Sample_Working.txt

remyah

Hi,

I am using 6.7.1 SP1.

My requirement is to decide the list of reviewers for user selection (in instantiation form ) based on the files selected while initiating the workflow job. I could not get the list of attached files in proprocessor and custom_instantiation.cfg.

Is any option available.

remyah

The following code gives the attached files. It can be used in custom_instantiation.cfg

elementlist=parent.document.getElementsByTagName('input');
for(i=0; i if((elementlist.name == "vpath") && (elementlist.value != "null")){
alert(elementlist.value);
}
}
}

Adam Stoller

Formatted for read-ability:

The following code gives the attached files. It can be used in custom_instantiation.cfg

    elementlist=parent.document.getElementsByTagName('input');
     for(i=0; i<elementlist.length; i++){
 if((elementlist.name == "vpath") && (elementlist.value != "null")){
   alert(elementlist.value);
 }     
       }
    }

DaveW2

I found that in modeller, if you set a global $CV with default value of $IW_FILES you'll have access to it from the custom instantiation screen the same way as other $CVs. It shows up as a semicolon separated list. $IW_FILES isn't in the default value pull down list... but if you type it in... it works.

But now... how to get it to a perl postProcess script!

Dave.

CRB

But now... how to get it to a perl postProcess script!

Dave.

does anybody know how to acheive that without having to write proprocess java class?

since we can get the list of attached files in the form, is there away to modify the list in the form? like either add another file or remove some?

Adam Stoller

does anybody know how to acheive that without having to write proprocess java class?

since we can get the list of attached files in the form, is there away to modify the list in the form? like either add another file or remove some?

I haven't tried this - but since the instantiation form is essentially controlled via a DCT which utilizes FormAPI / Javascript - can you access the javascript variable that contains the list of files attached to the job? If so, you should be able to modify that as you desire.

CRB

yes

, it was easy to access the $IW_FILES. i added it as an item in the custom instantiation form with its CV ID as name & pathid. i was able to get the value of the attached files and set it to anything i want. and using js popup i am able to see that the value of the CV changes. but in my external task (perl script), i dont get anything for attached files using task->getfiles().

i am trying to give the user the list of available files and have them select it from the custom instantiation form rather than browsering around the folder structure. so i used an inline cmd to get the available files and present them as options in checkbox item. and when the user hit submit -> onSave, i set the selected options as value of the IW_files (seperated with ; ).

update: i couldnt get the $IW_FILES value to actually change in the system so i did things little different to acheive my plans.

i set up the cmd of my external task as configurable variable. i added that as an item in the custom instantiation form. when the user selects the files they want to submit, i concat the options saperated by ;. then i add it at to the end of external cmd variable. that makes it an argument passed to my perl script. and you know the rest Smiley Happy

Adam Stoller

I'm glad you got things working (I think?) - However your description is rather confusing because you're talking about the instantiation form and then you're talking about an external task, and then you're talking about letting users select from a list. External tasks are post-instantiation, and thus a very different thing from the instantiation form. External tasks are fully-automated, and thus they do not allow users to interact and select things.

Perhaps if you cleared up your use of terminology it would make it easier to understand...

CRB

Sorry, i was in the middle of working on things and i didnt pay attention to my writing. but this is the story:

i have very simple workflow (wft1) : the user selects files from a specific folder in workarea -> new job -> selects wft1 from available workflows-> an external task gets invoked which runs a perl script (the perl scripts uses task->getfiles() to get the attached files then it does very complicated things with them).

i have the wft version and i wanted to convert it to wfm with minimum work, which turned out to be simple task. the exact same process just built with workflow modeler using the same perl script.

then i wanted to enhance it so the user won't have to browse to the folder to select the files. i changed it to where the user just clicks on new job -> selects wfm1 -> which brings up the custom instantiation form with available files to attach. since i am used to making things with wft, perl, and i wasnt very familiar with how wfm works, i didnt know how to get the selected files to my external task/perl script. that's where i needed to find a way to attach the selected files to the workflow and then my perl script will just pull them with task->getfiles() (and that s how i got involved in this thread). but attaching/adding the files to the workflow using postprocess cmd was going to require some java coding / maketool /fix the errors / maketool again... which i dont have time for. but as you see, i got to pass the selected files ( what was supposed to be "attached files") as an argument in the external command (configurable variable). then i changed the perl script from using task->getfiles() to take that argument and extract the files to be processed.

i know it sounds like very simple thing to do Smiley Happy but it didnt to me when i thought that i had to abandon the perl script and rewrite the whole thing in java...

the important thing: what i learnt today opened whole new doors for me Smiley Happy . i can convert all my wfts to wfms keeping most of the perl and cgi scripts with very minimal changes. of course i will eventually have to start making things in java, but that's gonna be for future projects.