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

Mulitple targets in PLC workflow

nipper

OK following the manual (6.7.2 SP Dev Guide - on Linux) for adding multiple sites to multiple Runtime Instances. Anyone do this ?

The issue (I think is with the Java Bean). I have 3 different branches going to 3 different RTIs (Prod, Marketing, and Intranet).

From the manual it says to replicate teh complete bean id="customer.teamsite.DeploymentService.OpenDeploy.DeploymentTargetMap" for each branch/RTI

When I do that it kills the GUI with an error in the servletd_out log complaining about multiple beans customer.teamsite.DeploymentService.OpenDeploy.DeploymentTargetMap

So it looks like I should have multiple entry="Prod/Marketing/Intranet" inside a single bean. I do that and the 1st 2 work (Prod/Intranet) but the 3rd deployment (Marketing) is completely bypassed.

I see some debug information (true/false) in the servletd log and assume that is from the WF, how can I tell what it is tracking ?

I have walked through the manual 4 times and am pretty confident I have not missed something, but that is certainly possible.

Anyone have this working ? Pointers ?

Find more posts tagged with

Comments

Faizi

OK following the manual (6.7.2 SP Dev Guide - on Linux) for adding multiple sites to multiple Runtime Instances. Anyone do this ?

The issue (I think is with the Java Bean). I have 3 different branches going to 3 different RTIs (Prod, Marketing, and Intranet).

From the manual it says to replicate teh complete bean id="customer.teamsite.DeploymentService.OpenDeploy.DeploymentTargetMap" for each branch/RTI

When I do that it kills the GUI with an error in the servletd_out log complaining about multiple beans customer.teamsite.DeploymentService.OpenDeploy.DeploymentTargetMap

So it looks like I should have multiple entry="Prod/Marketing/Intranet" inside a single bean. I do that and the 1st 2 work (Prod/Intranet) but the 3rd deployment (Marketing) is completely bypassed.

I see some debug information (true/false) in the servletd log and assume that is from the WF, how can I tell what it is tracking ?

I have walked through the manual 4 times and am pretty confident I have not missed something, but that is certainly possible.

Anyone have this working ? Pointers ?

You are correct, multiple entry node will come into single bean.
If the two of three is working fine then 3rd one also should work. You may check the regex putted into value tag for that branch.
You may also check the custom_instantiation screen file and workflow condition link Javascript code.
You may also check "KB article #6025" article from support site.

Adam Stoller

...
I see some debug information (true/false) in the servletd log and assume that is from the WF, how can I tell what it is tracking ?
...

While not the focus of this thread, I can answer this question.
What you're seeing is the output of all SCRIPT variable evaluations whenever the WFM is instantiated.

I have a case open with Support about this - while its nice to see that information when you're trying to debug something, it would be nicer to be able to disable that output when your WFMs are functional as all it does is clutter up the log file.

nipper

OK, so here is the scoop.

Inside the IPM, the TagetNode is hardcoded to production for the Production Deployment.

I modified it to the correct value then it worked.

However, I was trying to make a generic WF for 3 branches, using FormAPI to choose the correct TargetNode based on the specific branch I submitted from.

Worst case, I make 3 copies, but that sucks. There has to be a way to make the IPM read the target from custom_instantiation.cfg instead of hard coding it. That is my next task. (unless, of course I missed something)

Andy

AuditPlanReport.rptdesign

Adam Stoller

As a guess, you'd probably have to make the target a datasource variable so that you can run some code during the instantiation which will read your configuration file and provide the right value.

Alternatively (and probably my preference) would be to have an externaltask early in the workflow that reads the configuration file and sets the task variable on the deployment task to have the right information.

Another alternative, though probably less desirable, would be to use a script variable for the task variable and write the logic in javascript - it's an alternative but not (IMO) a very good one given what you've indicated.

nipper

As a guess, you'd probably have to make the target a datasource variable so that you can run some code during the instantiation which will read your configuration file and provide the right value.

Alternatively (and probably my preference) would be to have an externaltask early in the workflow that reads the configuration file and sets the task variable on the deployment task to have the right information.

Another alternative, though probably less desirable, would be to use a script variable for the task variable and write the logic in javascript - it's an alternative but not (IMO) a very good one given what you've indicated.

BUt that is what is screwed up, the custom_instantiation.cfg already has targets. They can be development and production, but it is trivial to change. A little more work to have 3 production tags and only allow one, depending on which branch is in use. So the WF already is build for that, and has the correct information. I just need to get it into the task variable.

Adam Stoller

BUt that is what is screwed up, the custom_instantiation.cfg already has targets. They can be development and production, but it is trivial to change. A little more work to have 3 production tags and only allow one, depending on which branch is in use. So the WF already is build for that, and has the correct information. I just need to get it into the task variable.

Is the prompt on the instantiation form a "configurable variable" ?
(it should be)
Is the configurable variable a "Global" or "Job" variable?
(not sure which may be needed, if you're using one and it isn't working, try doing it using the other one)
Is the task variable set up to reference the same "configurable variable"?
(it should be)

nipper

Is the prompt on the instantiation form a "configurable variable" ?
(it should be)
Is the configurable variable a "Global" or "Job" variable?
(not sure which may be needed, if you're using one and it isn't working, try doing it using the other one)
Is the task variable set up to reference the same "configurable variable"?
(it should be)

Yes it becomes a global variable, I tried setting the task variable to the global variable but for some reason it did not fly.