OpenDeploy not working from OOTB configurable_author_submit workflow (TS741)

Hello,

this could be a thread under OD, but since I have OD generally working but not from the workflow, I've put it here...

I wanted to set up the OOTB configurable_author_submit workflow as an alternative to our hefty pre-existing workflow. Generally the workflow is working, except for the deployment although it doesn't show any errors and the Job finishes and is removed.

I read in the "legacy" ts_71_wfdev_v01_en.pdf guide that solutions/wft_opendeploy.ipl starts the deployment, so I simply edited it to intervene in the OD invocation to use our usual deployment conf file:

$CLIENT_CMD = $ODCMD_EXE." ".$tmpdeployName." -k filelist=\"$filelist\" -inst NLMCHG";
print ("DEBUG: OD Command = $CLIENT_CMD");
# ---- RUN OD CLIENT COMMAND
open(PIPE, "$CLIENT_CMD 2>&1 |");
while(<PIPE>){
$results .= $_;
}

...this is what I want: it will use the filelist the workflow makes (lines like htdocs/...), our deploy script (nlm.xml, defined in configurable_author_submit.cfg) and write OD logs with "NLMCHG" inserted in the filename for tracking. But it isn't which convinces me that the workflow isn't using solutions/wft_opendeploy.ipl at all, but something else (I proved it by changing $tmpdeployName to something that doesn't exist).

I tried tracking it through configurable_author_submit.wft et al, but getting nowhere fast - I'm sure I am missing something obvious, but I'm blocked now, so need a pointer...

Can someone tell me how the workflow kicks off the deployment? I suspect I am looking at an outdated guide as the information appears incorrect, but I can't find one that would cover what I want.

Thanks for any help,

Find more posts tagged with

Comments

nipper

If you look at the WFT it runs a Java task:

declare_task('deploy',
name => $localizer->format('deploy_task.name'),
description => $localizer->format('deploy_task.description'),
type => "externaltask",
owner => $iw_areaowner,
areavpath => $iw_workarea,
command => "http://$web_host/iw-cc/urlexternaltask",
variables => {
"ClassName" => "com.interwoven.ui.teamsite.workflow.task.urltask.DeployURLExternalTask",
"odDeploymentName" => $wft_config->get_value('deployment_name')
});

deployment_name is defined in configurable_author_submit.cfg (initial is test.xml) and turned off by default.

# Should there be a Deploy task at the end of a job to deploy files
# after they have been submitted?
deploy_task=no
deployment_name=test

HurricanesFan

Nipper,

yes, I saw the Java task ($localizer etc) in the wft, that's where I got lost. So it is not using wft_opendeploy.ipl then?

In configurable_author_submit.cfg I have:

deploy_task=yes
deployment_name=nlm

...and the deployment is using nlm.xml (writing logs like rcv.nlm.nlm-def.teamsite.log).

But I need to find out how to configure it properly - I was hoping that, if I could see where it was invoked, I could work it out (hacking a perl script would have been easy for me).

I think I need to track down the relevant guide book, maybe I have to go to Support and ask.

Cheers

nipper

You should be able to look at some of the newer deployments to see how it grabs the filelist. IIRC, test.xml does an area diff. You will want a filelist, which the URL task will provide.

You can also change the WFT to use an external task instead of a URL task and have it kick off wft_opendeploy.ipl

HurricanesFan

I think the last sentence is the best way forward for me.

I have made the following change in the wft to call the ipl (which it does), although I have a little work to do to get it working properly.

    declare_task('deploy',
                 name        => $localizer->format('deploy_task.name'),
                 description => $localizer->format('deploy_task.description'),
                 type        => "externaltask",
                 owner       => $iw_areaowner,
                 areavpath   => $iw_workarea,
##150211 Change
                 command     => "/usr/nlm/iw/iw-home/TeamSite/local/config/wft/solutions/wft_opendeploy.ipl");
#                command     => "http://$web_host/iw-cc/urlexternaltask",

HurricanesFan

A note that I have this working now. Nipper sparked the idea that sent me in the right direction.

So I changed:

1. the wft (above) to use wft_opendeploy.ipl instead of the Java task.

2. Put in a mapping of branch|deployment in wft_opendeploy.cfg

3. Changed wft-opendeploy.ipl in multiple places to make it work, especially to:

- extract the branch vs deployment mapping in wft_opendeploy.cfg

- make the correct iwodstart invocation

(I'll probably rewrite the ipl if we end up using this workflow)

Not sure if the Java task would have worked or not, but I didn't find any documentation on how to configure it (the latest 'legacy' guide I have says wft-opendeploy.ipl run the deployment, so nothing there), so it was easier for me just to hack the ipl to make it work as at least it was getting the correct arguments from the workflow.

Cheers

Adam Stoller

I'm glad you got it working - you're not going to find informaiton about the Java implementation for deployments in he Legacy Workflow guide - you would need to look at the WFM guide for that - and even then it won't really give you a guide towards customizing the innards - just the pieces that the OOTB code allows you to customize.

If you want to do full customization of a Java deployment class you would need to create your own class based on the same base class (DeployURLExternalTask I believe) - which is an un-documented class and thus not officially supported (though it doesn't stop a number of us from doing so)

HurricanesFan

I have already marked this as solved, but I wanted to ask a more philosophical question about workflows (maybe I'll make it a new thread if it doesn't attract answers in this solved one).

We will probably need to make a new workflow which will involve us adding some of our own special tasks such as passing the files through an html validator and a link checker (they must pass validation before they can be deployed), writing new files details to an external database, attaching related files (eg DCRs) etc.

I am trying to work out which is my best option for making this new workflow:

1. adapt an OOTB workflow such as configurable_author_submit.wft mentioned here (as it already does some of the tasks we need - review, submit and, now, deploy),

2. use Workflow Modeller to do it (I haven't used WM before, not sure if it can add non-standard tasks like ours)

3. or write a brand new workflow from scratch.

What does the panel think?

Cheers

Adam Stoller

The general leaning would be to use WFM over WFT since WFM is newer and likely to be around - and it does provide a reasonable UI for creating workflows.

That said, the decision could lean towards WFT if you will need to be able to instantiate the workflow from the command line with situational-specific parameters (this can be done in WFMs using a task to retrieve information and perform the operation, but its a bit more straight-forward [IMO] in WFT)

You can use Perl-based or Java-based external tasks and/or CGI tasks in both WFTs and WFMs - so that's not really a factor.

Logic operations in WFMs are JavaScript based, whereas they are Perl-based in WFTs - again, it's a matter of choice / preference, and should only be a deciding factor if you believe that you can only achieve what you want using one or the other.

If you are using SitePublisher / LiveSite - you would probably be better served by making a copy of the OOTB PLC WFM and modifying that to fit your needs, other than that - I'd say start from scratch and reference similar worfklows (WFT or WFM) as you go, as needed, for information required in the implementation (e.g.: Commands and ClassName attributes and such). I don't think many of the OOTB WFTs are particularly good for using as a basis for custom implementations as that carry along a lot of baggage that you may not need which will just make them more complex / confusing / difficult to maintain. The same is pretty much true for WFMs - though more because creating a copy of a WFM is a bit tricky. If you start from scratch - you're in control and you should be able to clearly design / implement / document everything you do.

HurricanesFan

Hmmm. I will probably be needing to pass a number of user-defined variables, either as job variables (iwjobvariable -g) or via files named for the Job. I am tending to lean towards wfts/perl/CLTs because I know those better and time might be a factor. I doubt we will be using LiveSite - money is another reason we probably won't have either LiveSite or Workflow Modeller.

If it would be relatively easy to incorporate our special oddball tasks (file validation etc) into a workflow created by Workflow Modeller, I would have a case to make for us buying it, but I suspect that wouldn't be so easy.

This is all part of a CMS Evaluation project, and it looks like TS > Typo3 > Drupal for our needs (yay), so assuming TS is the chosen one, the next step is to decide a workflow and the evaluation team are actually quite happy with the OOTB configurable_author_submit workflow as a minimalist model as "simple & fewer clicks" is their mantra. So I am thinking I can use that as the base and try adding the 4-5 other specific tasks we need. Otherwise, as you say, I'll have to make a wft workflow from scratch and borrow a bit from our current massively overdone and confusing workflow.

Thanks Ghoti. As always there is no substitute for good analysis in the first place.

Adam Stoller

I believe that there is no extra cost or license required for WFM - so that should not be a deciding factor.

Your options are basically:

WFT, Perl, CLT
WFM, JavaScript, Perl, CLT
WFT, Perl and/or Java
WFM. JavaScript, Perl and/or Java

In WFTs - Perl is used for customizing the instantiation, generating the job spec.

In WFMs - JavaScript / FormAPI is used for customizing the instantiation and for conditional logic within the model that gets evaluated into the job spec.

In either WFT or WFM you can use Perl or Java / CSSDK for creating your external and/or CGI tasks.

Perl is faster to develop/debug (IMO) because it doesn't involve compilation and/or server restarts.

Java is more efficient since it can interface directly with the objects and functionality of TeamSite without having to initiate new shell processes all over the place to run CLTs. Also, it tends to be easier to find folks with decent Java experience / abilities than it is to find folks with decent Perl experience / abilities - so the long-term picture for maintenance also tends to favor Java in that regard.

HurricanesFan

I agree with all of that.

It would be nice for me to learn more about using Workflow Modeller and Java to make our workflow, but the bottomline is I am proficient in perl so it will be much quicker for us if I go for the first option, especially as it will be quite a large workflow anyhow.

I know many people frown on calls to the server CL, but they work just fine and can be tightly logged by me.

This was a helpful chat.

Cheers.

nipper

It is also not an either/or proposition, with respect to WFM and perl. You can certainly kick off perl scripts with WFM. That works fine. Customizing WFM is done with the GUI, the custom_instantiation.cfg (which basically is a DCT for the workflow startup) and a few WF variables (which use a JS like language).

Adam Stoller

Understood - I like cranking things out in Perl too (though I have gotten to appreciate the CSSDK when I use it) - I just wanted to make sure you weren't limiting your options based on a misconception about cost (WFM is not extra) or the ability to use either programming language for external / cgi tasks in either workflow type.

In many respects, WFM may be faster to crank out the general workflow - and you can still use Perl / CLTs to implement the various external / cgi tasks you want. But if you're happy with WFTs - go for it.

HurricanesFan

Thanks Ghoti & Nipper, this was all useful information.

I am not sure why I thought Workflow Modeller cost extra, perhaps it used to - in the days before the .wft workflows were referred to as "legacy" workflows...

It does give me the option of trying Workflow Modeller at my leisure, even if I need to write our main workflow the old-fashioned way.