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

passing variables into DCT

pedamale

Hi,

Can anyone tell me if it is possible to pass variables from workflow into a DCT ?

Thanks and regards,
Pedamale

Find more posts tagged with

Comments

nipper

While what you want to do is technically possible, what are you trying to do ? What is your use case ?

I can think of a way to do this, but before I explain I want to make certain you are not heading down
the wrong road. This is not a normal request which makes me wonder if you are trying something different.

Andy

pedamale

We have one teamsite instance (for all dev, QA and prod) and three Weblogic instances (each for dev, QA and prod), and so many database instances.

I have created 3 workflows that point to each of them pointing to the different weblogic instance. I do not wish the templates be seperated the same way, as any change needed in the template will have to be repeated thrice. I want to parameterize the process, so that one template will work for all the three instances

Thanks and regards,
Pedamale

nipper

OK, makes sense.

I do not understand how a WF would pass state information to a DCT. It is usually
the other way around, based on where the DCR is in the cycle (WA, Stage, Prod)
determines which table the DCR gets placed into, & what instance of WLS is used for
preview. We do that.

So if I am previewing from WA, the tpl (which just does a redirect) looks at the path
and points to the appropriate instance of WLS

does this help ?

Andy

Adam Stoller

I can think of several ways to handle this - one would be to use a branching structure such that you can tell by the areavpath whether you should be using the "DEV", "QA" or "PROD" environment - and have as part of your workflow process the migration of approved work from DEV->QA and then from QA->PROD (and perhaps handle rejection from PROD->QA and/or QA->DEV).

If you want to use EA's - you can do that in the workflow with the eastartop/eafinishop task attributes (or as workflow variables with wfvarstartop and/or wfvarfinishop attributes) - thus you could call the same scripts and such and have those scripts check the EAs or job variables to determine whether they should be functioning in DEV, QA, or PROD mode.

If you really want to do it from the workflow to the DCR - then I think you'd have to use the ea*op attributes -- but this presupposes that the DCR exists. If you're trying to get it handled at the time the DCT is initially rendered, you'd have to come up with some means of transferring the information to a process that could be handled by an inline script - but that seems *very* fragile and subject to a *lot* of work trying to get it to work in all circumstances.

If you can take care of making sure the DCR pre-exists (perhaps earlier in the workflow process) - then you can utilize the EAs and allow callouts to retrieve those EAs to determine their mode. (mind you, iwextattr is not "cheap" as far as overhead is concerned, but ...)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

pedamale

The workflow always ensures that a DCR is available. The very first step ensures this (A blank DCR is generated, if there is none). Can I have an example how this ea*op can be used ?

Thanks and regards,
Rajesh

Adam Stoller

Start with RTFM - essentially you can specify EAs to be set on all the files associated with the job either when the task is activated (eastartop) or deactivated (eafinishop).

I've never personally used them, but I've also rarely run into a case where I needed to. Your situation sounds like it might be able to benefit from them.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com