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

Add instance to WFM Deployment task

13adam13

I cannot figure out how to add a definition for instance to openDeploy command.
I am using the DeployURLExternalTask task, which is the default for the WFM OOB.

I have tried just adding an OD Variable named inst. Though this approach does work when you need to add the iwdd variable for DataDeploy, it does work for adding the instance name.

Anyone tried doing this successfully?
anyone aware of any documentation for the com.interwoven.ui.teamsite.workflow.task.urltask.DeployURLExternalTask class?

Find more posts tagged with

Comments

Faizi

I cannot figure out how to add a definition for instance to openDeploy command.
I am using the DeployURLExternalTask task, which is the default for the WFM OOB.

I have tried just adding an OD Variable named inst. Though this approach does work when you need to add the iwdd variable for DataDeploy, it does work for adding the instance name.

Anyone tried doing this successfully?
anyone aware of any documentation for the com.interwoven.ui.teamsite.workflow.task.urltask.DeployURLExternalTask class?

Hi 13adam13,
OD variable name/value pair works with deployment configuration file. Whatever variables you have defined in deployment configuration file. If you able to define instance definition in deployment config file then you can use it.
There is not any variable related to OD instance in DeployURLExternalTask class file.
But as you said that it works with IWDD variable then it also works with IWODCMD there might be some missing. Have you tried odinst instName?

Hope this helps.
Thanks,

13adam13

Have you tried odinst instName?

Faizi, thanx for the reply. I have tried adding an "OD Variable" called inst and I have tried adding a task variable called odInst (patterened after the odDeploymentName task variable), but neither seemed to effect the instance name of the deployment.

I am doing a filelist deployment, passing in the name of the filelist. The OOB deployment task allows me dynamically define the variable used to specify a unique filelist, but keeps failing when two workflows try this simultaneously.
If I turn on queueing, then when three workflows run at the same time, the middle one won't get deployed (based on my understanding of how that works).

Any thoughts on how to use the OOB deployment task to run the same deployment configuration many times concurrently?

Adam Stoller

Any thoughts on how to use the OOB deployment task to run the same deployment configuration many times concurrently?

You are assuming that the OOTB java class for initiating deployments from workflows includes an option for setting an instance (inst) parameter - I haven't looked at it, but based on how the OOTB java classes were written for Email handling (in TS, not LiveSite apparently) - I'd say that's making a big assumption. You may have to write your own java class - or fall back to using a Perl script through an ExternalTask instead.

Natasha

Faizi, thanx for the reply. I have tried adding an "OD Variable" called inst and I have tried adding a task variable called odInst (patterened after the odDeploymentName task variable), but neither seemed to effect the instance name of the deployment.

I am doing a filelist deployment, passing in the name of the filelist. The OOB deployment task allows me dynamically define the variable used to specify a unique filelist, but keeps failing when two workflows try this simultaneously.
If I turn on queueing, then when three workflows run at the same time, the middle one won't get deployed (based on my understanding of how that works).

Any thoughts on how to use the OOB deployment task to run the same deployment configuration many times concurrently?

Hi Adam,

I am also facing the same issue.
May I know how you enabled queueing - using pendSessions or pathRegistryChecking attribute?

Natasha.
TS6.7.1 SP1, ls3.0.1,OD6.1.1

13adam13

May I know how you enabled queueing - using pendSessions or pathRegistryChecking attribute?

I didn't enable queueing because, according to the documentation, if there were three attempted simultaneously, the middle one would be overwritten with the third.

Natasha

I didn't enable queueing because, according to the documentation, if there were three attempted simultaneously, the middle one would be overwritten with the third.

Would you mind sharing the manual name as I couldn't find it in the manual for OD6.1.1?

Thanks,
Natasha.

Adam Stoller

I didn't enable queueing because, according to the documentation, if there were three attempted simultaneously, the middle one would be overwritten with the third.

It depends on the type of queuing.

With sender side "

pendSessions

" - yes, if you have deployment X running and attempt to start up N more instances of deployment X, then the last one initiated while the first one was running will be the next instance run and all the intermediate attempts to queue the deployment will be discarded. This is reasonable if you are doing dir-diff type deployments only.

With receiver side "

pathRegistryChecking

" with "

serializeDeploymentSetUp

" (see support KB 61497 for details) - the receiver will cause concurrent transactional deployments to become serialized such that each of the N instances of the deployment (based on target path, not deployment name or instance name) will be processed individually. This is useful for transactional filelist deployments.

The basics of "

pendSessions

" and "

pathRegistryChecking

" can be found in the OD Reference manual, and possibly other OD manuals)

Natasha

It depends on the type of queuing.

With sender side "
pendSessions
" - yes, if you have deployment X running and attempt to start up N more instances of deployment X, then the last one initiated while the first one was running will be the next instance run and all the intermediate attempts to queue the deployment will be discarded. This is reasonable if you are doing dir-diff type deployments only.

With receiver side "
pathRegistryChecking
" with "
serializeDeploymentSetUp
" (see support KB 61497 for details) - the receiver will cause concurrent transactional deployments to become serialized such that each of the N instances of the deployment (based on target path, not deployment name or instance name) will be processed individually. This is useful for transactional filelist deployments.

The basics of "
pendSessions
" and "
pathRegistryChecking
" can be found in the OD Reference manual, and possibly other OD manuals)

Thanks Ghoti for the response.
The deployment which gets initiated has names like "OpenDeployWebRootfp3gajh2fp3gajh3,OpenDeployWebRootfp3gajklfp3gajkm. Basically, different instances of the deployment are getting called. Now the problem is when the user selects to deploy 3 different pages by running the author submit workflow and chooses the same time for deployment like 5 a.m., only 1 deployment is successful 2 are failing giving the following error :-
[HTML]
Receiver-ERROR: ERROR: commit-failed.
LIB: 2008-12-26 09:01:18 ERROR: Failed to deploy local_directory[.] of area[/usr/iw-home/tmp/LiveSite/workflow/fp3gajjn] for filelist[/usr/iw-home/tmp/LiveSite/workflow/fp3gajjn/cache.WebRoot.fp3gajjnfp3gajjo.filelist]
[/HTML]
The deployment is a 2 tier deployment, with the first one being filelist deployment and second one is a directory diff deployment.
Could you please advise that we should add both pathRegistryChecking="yes" in the odbase.xml(middle tier server - receiver for the first deployment which is filelist based) and pendSessions="yes"( for the second deployment which will run from middle tier to final web servers) in the same odbase.xml in order to enable queueing in such a scenario?

Thanks,
Natasha.

Adam Stoller

Thanks Ghoti for the response.
The deployment which gets initiated has names like "OpenDeployWebRootfp3gajh2fp3gajh3,OpenDeployWebRootfp3gajklfp3gajkm. Basically, different instances of the deployment are getting called. Now the problem is when the user selects to deploy 3 different pages by running the author submit workflow and chooses the same time for deployment like 5 a.m., only 1 deployment is successful 2 are failing giving the following error :-
[HTML]
Receiver-ERROR: ERROR: commit-failed.
LIB: 2008-12-26 09:01:18 ERROR: Failed to deploy local_directory[.] of area[/usr/iw-home/tmp/LiveSite/workflow/fp3gajjn] for filelist[/usr/iw-home/tmp/LiveSite/workflow/fp3gajjn/cache.WebRoot.fp3gajjnfp3gajjo.filelist]
[/HTML]
The deployment is a 2 tier deployment, with the first one being filelist deployment and second one is a directory diff deployment.
Could you please advise that we should add both pathRegistryChecking="yes" in the odbase.xml(middle tier server - receiver for the first deployment which is filelist based) and pendSessions="yes"( for the second deployment which will run from middle tier to final web servers) in the same odbase.xml in order to enable queueing in such a scenario?

Thanks,
Natasha.

The error message you showed is not indicative of a deployment failure that would be fixed by the settings being discussed - though it might help.

IFF the deployments are being done transactionally, then yes - you would probably be well-served by adding the

pathRegistryChecking

serializeDeploymentSetUp

, and

pendSessions

settings to the middle-tier server's odbase.xml - to serialize the filelist deployments being received to there and queue the dir-diff deployments being sent from there.

However, as I stated, the error message is not indicative of the issue that these settings resolve - and you should probably be looking more carefully in all the log files on both sides of the deployments to figure out the actual cause of your deployment failures.

13adam13

With receiver side "
pathRegistryChecking
" with "
serializeDeploymentSetUp
" (see support KB 61497 for details) - the receiver will cause concurrent transactional deployments to become serialized such that each of the N instances of the deployment (based on target path, not deployment name or instance name) will be processed individually.

Since reciever side "

pathRegistryChecking

" only addresses what the reciever does after it recieves a deployment request, I don't think that it will help with the issue that I cannot start 2 OD instances on the base that use the same Config file name, even though they have different parameters.

I haven't played with this concurrency stuff much, so please let me know if I am not understanding correctly.

Adam Stoller

Since reciever side "
pathRegistryChecking
" only addresses what the reciever does after it recieves a deployment request, I don't think that it will help with the issue that I cannot start 2 OD instances on the base that use the same Config file name, even though they have different parameters.

True - but that's where instance parameters (

-inst unique_string

) come into play.

13adam13

True - but that's where instance parameters (
-inst unique_string
) come into play.

Adding the instance parameter comes into play on the base, as well as on the reciever. The problem is that I cannot add it, so the base thinks that they are identical deployments, even though they are not.

I have resigned myself to the fact that the WFM OD task just doesn't have the ability to do what I need done. I guess I will file a feature request.

Migrateduser

Hi,

In the task variables of your deploy Task, just add "odDeploymentInst" with the instantiation value you want to use.

Not in the "Open Deploy Variables"

Greg.

Adam Stoller

Hi,

In the task variables of your deploy Task, just add "odDeploymentInst" with the instantiation value you want to use.

Not in the "Open Deploy Variables"

Greg.

Is there a way (within the WFM interface) to set the value for odDeplomentInst to be either the jobid or taskid at instantiation time?

If not, it would seem that one has to create their own class that extends DeployURLExternalTask (not documented in CSSDK javadocs because it's not actually part of the CSSDK - sigh) in order to do this dynamically.

Migrateduser

I know that some Teamsite Macro variables exist like %workflowid; and %taskid; and could be used in the modeler tasks; but I never try.

It seems those macro variables could only be used for EA finish and start Op

Greg.

Migrateduser

Just use

${jobId}

in the variable value

moulikk

Hey did assigning ${jobId} as value really work for you?

In my Deploy Task, Task Variables, I set odDeploymentInst to ${jobId} That did not get evaluated at all. Neither did $jobId.

I am trying to do the same thing, I want my odDeploymentInst variable to be populated with either the taskid or jobid.

Adam Stoller

Hey did assigning ${jobId} as value really work for you?

In my Deploy Task, Task Variables, I set odDeploymentInst to ${jobId} That did not get evaluated at all. Neither did $jobId.

I am trying to do the same thing, I want my odDeploymentInst variable to be populated with either the taskid or jobid.

I created my own custom Deploy class (extending DeployURLExternalTask) in order to get this (and several other things) to work the way I wanted it.

I don't believe you can reference the jobid (or taskid) in the WFM because it doesn't exist until after the workflow is instantiated.