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; } } }

Can custom workflow code be aware of how WF was initiated? (submit, tt_data, ...)

System

Is there a variable accessible by the workflow custom code that I can check to see what initiated the workflow (submit, tt_data, new job, ...) ?

I recently discovered that our files marked "private" were being deployed to production when using "tt_data" and had to implement custom logic in our workflows to remove the "private" files from the workflow.

We use the same workflow weather we are submitting / deploying one file or several thousand, and the additional check of the "private" flag will cause the workflow to take much longer when having to process thousands of files.

My install is on TS 6.7.1 - Windows.

Find more posts tagged with

Comments

HKN1104

Is there a variable accessible by the workflow custom code that I can check to see what initiated the workflow (submit, tt_data, new job, ...) ?

I recently discovered that our files marked "private" were being deployed to production when using "tt_data" and had to implement custom logic in our workflows to remove the "private" files from the workflow.

We use the same workflow weather we are submitting / deploying one file or several thousand, and the additional check of the "private" flag will cause the workflow to take much longer when having to process thousands of files.

My install is on TS 6.7.1 - Windows.

you can define it in available_models.xml not to submit after tt_data.

Adam Stoller

you can define it in available_models.xml not to submit after tt_data.

I don't think that's a valid response. It is true that if you don't configure a workflow for the tt_data command, you won't be able to initiate a submit operation from "Finish"ing a DCR - but I believe the original premise is that the workflow is currently used (rightly) for both tt_data and submit (and/or new_job)

I think there is a question though - if "private" files are getting deployed as part of a tt_data initiated job - what actually caused those private files to be connected to the job in the first place?

Was it a "private" DCR amongst a bunch of non-private DCRs in the same data directory?

Was it a private "related asset" to the DCR?

I can certainly understand something like this happening when doing a mass-selection and Submit, but I don't understand how this happened due to tt_data

Migrateduser

Thank you Ghoti.

Within my company, my team (which consists of software developers) manages our JAVA applications and the Velocity templates associated with the app. We place our Velocity template code within the same DCR that our Webmaster's use to update basic web page elements. Prior to any change to the app, we stage the Velocity template code within the TeamSite workarea and mark them "private" to prevent them from being deployed prematurely (or so we thought). Apparently some of our users don't seem to notice (or care) that these files are marked "private" and proceed to edit the “private” generated file (which brings up the DCR edit screen). When they click on the "Finish" button within the DCR they have no problem kicking off our submit & deploy workflow, and the "private" file gets deployed to production which in turn breaks the application (as it wasn't ready for the changed file). Although the files are deployed to prod, they don’t get submitted to the branch’s Staging area.

I have a "fix" in place within my custom workflow code to remove any files marked "private" which works great when the workflow is initiated by "tt_data" as it will only have one or two files attached. My concern is that the same workflow is used when initiated by "submit", and those workflows could have as many as three to four thousand files attached which would take significantly longer to process the extra code. It’s my understanding that the “submit” initiated workflows automatically filter out any “private” files that were passed to it as they are not technically able to be submitted. Therefore I thought it best to not use the custom code to remove private files when initiated by “submit” as it would be redundant, only I cannot seem to find a way from within the workflow code to differentiate weather it was a “submit” or “tt_data” initiated workflow.

Am I correct in assuming that a “submit” initiated workflow automatically filters out “private” files?

Any ideas on how I can identify how the workflow was initiated (“submit“ vs “tt_data”)?

ISCBorisB

Am I correct in assuming that a “submit” initiated workflow automatically filters out “private” files?

No. Private Files get attached to the workflow just like any other Files.

The only difference is that any flavor of "Submit" action (Submit Task,
Submit CLT, Submit methods, etc...) do NOT submit Private Files to Branch
STAGING Area.

Migrateduser

No. Private Files get attached to the workflow just like any other Files.

The only difference is that any flavor of "Submit" action (Submit Task,
Submit CLT, Submit methods, etc...) do NOT submit Private Files to Branch
STAGING Area.

Is that the case with TS 6.7.1? With every test I perform (by selecting individual files, or entire folders and clicking on the "Submit" button), the "private" files are never visible by my workflow.

ISCBorisB

Is that the case with TS 6.7.1? With every test I perform (by selecting individual files, or entire folders and clicking on the "Submit" button), the "private" files are never visible by my workflow.

Yes, it is the case for 6.7 as well, for both WF Models.
You can check that by configuring OTB Submit WF to allow it in the "New Job" Mode and runnung it directly.

The difference with "New Job" is that in "Button Submit" Mode WF gets called through special TS Command,
iw.group.submit (not sure what it's mapped to, perhaps "wizard_submit_options.jsp"). Whatever it is, it
performs some preliminary validation, including the check if there is anything there to submit in the first
place.

It is possible that iw.group.submit Command filters out Private Files. In general though you cannot rely on
this behavior. "Private File" is by definition the File that belongs to the Workarea, period. Beside the
fact that these Files are not submitted, I am not aware of any special treatment for them.

Adam Stoller

Are these "private" files named in a consistent manner or located in an isolated directory?

If not - can they be?

If you can do that, then all you need to do is add filters to your deployment configuration file (for both source and target side) to have the deployments completely ignore the existence of those files.

Migrateduser

Are these "private" files named in a consistent manner or located in an isolated directory?

If not - can they be?

If you can do that, then all you need to do is add filters to your deployment configuration file (for both source and target side) to have the deployments completely ignore the existence of those files.

The files are typically existing files throughout the workarea that have nothing unique enough to them to use as a basis for any type of filtering (other than being marked private).

Based on ISCBorisB's response I need to research the differences between "button submit" and iw.group.submit to see if I can guarantee that the tt_data initiation of the workflow is the only way these "private" files can get added to the workflow (between "submit" & "tt_data")... Once I've done that and if tt_data is deemed to be the only way these "private" files can be added to the WF, then it looks like the only option I may have would be to break out my workflows into two separate workflows (one for each "submit" & "tt_data"), rather than using just one that dynamically performs the "private" status check only when initiated by "tt_data".

Thank you for your responses..

ISCBorisB

...I need to research the differences between "button submit" and iw.group.submit...

Just to clarify a bit...

When you click a "Submit" Button, iw.group.submit Command gets executed.
If your Submit request is valid, the command will in turn instantiate submission workflow.

Other "Submit" Scenarios do NOT go through iw.group.submit, that's the difference

Adam Stoller

The files are typically existing files throughout the workarea that have nothing unique enough to them to use as a basis for any type of filtering (other than being marked private).

Based on ISCBorisB's response I need to research the differences between "button submit" and iw.group.submit to see if I can guarantee that the tt_data initiation of the workflow is the only way these "private" files can get added to the workflow (between "submit" & "tt_data")... Once I've done that and if tt_data is deemed to be the only way these "private" files can be added to the WF, then it looks like the only option I may have would be to break out my workflows into two separate workflows (one for each "submit" & "tt_data"), rather than using just one that dynamically performs the "private" status check only when initiated by "tt_data".

Thank you for your responses..

If you're handy with Java, you will probably find that a URL ExternalTask running a CSSDK program to plow through all the files attached to the job to check whether they are marked private or not (and detach the ones that are) will be much more efficient than a Perl script running iwprv on all the files.