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

How to integrate workflows and QA/LIVE delivery stages?

Markus_Schorer

Hi,

we're trying to get our heads around the following issue:

- we have a magement stage, we want a delivery stage for QA, we have a delivery stage for Production

- content is created on the management stage and once "ready" should be published to the QA stage where it can be viewed in a "live" environment (the preview on the mgmt-stage is not enough)

- if it's ok, it can then be published to the LIVE environment

Now the questions:

- how do the workflows assigned to a CTD integrate with deployment workflows (if at all)

- if we have multiple delivery stages (for different purposes), how do we decide which content goes where?

The docs do touch all of these issues, but we cannot find a full blown scenario with workflows.

Any help appreciated,

markus

Find more posts tagged with

Comments

Markus_Schorer

Hi guys,

any thoughts on this? Or is the question wrong?

Can you point me to docs explaining ththe mentioned area?

_Any_ help appreciated,

markus

Clay Johnson

Ifyou’re trying to deploy the same publish/unpublish job to multiple stages insuccession, the OOTB deployment workflow and programs provide some means to doso.

Oneoption is an approach like vgnWfDeployToAllStages. It relies on stageordering as configured on the lower half of the Site/Deployment tab. It alsorelies on conventions how the execute/complete/cancel programs are used forerror handling and lifecycle of the job. Make sure you understand theseconventions if you intend to write your own workflow definition. Failure tocomplete/cancel a job can leave it, and its contents, in limbo. I believe thisOOTB workflow iterates the job immediately to all stages. One likely changeyou may want is some intervening, manual approval step in the loop, so you cancontrol the iteration to each stage.

Alimitation of vgnWfDeployToAllStages is that it assumes thesame job is going to all stages. If instead you need the flexibility to changethe contents of the job at each stage, then it’s probably not the model youwant. Instead, you might consider vgnWfDeployToStage as a subprocess program in alarger workflow responsible for creating jobs and ordering the stages. But jobcreation is a non-trivial api activity that you would have to assume for thisadditional flexibility. See DeploymentClient for api job creation.

From: eLink Entry: Discussion Group - WebExperience Management [mailto:v7webcontentmanagement@elinkkc.opentext.com]
Sent: Monday, July 25, 2011 3:47 AM
To: eLink Recipient
Subject: How to integrate workflows and QA/LIVE delivery stages?

How to integrate workflows and QA/LIVE delivery stages?

Posted by mschorer@pocketkings.ie (Schorer, Markus) On 2011/07/25 04:43

Hi guys,

any thoughts on this? Or is the question wrong?

Can you point me to docs explaining ththe mentioned area?

_Any_ help appreciated,

markus

[To post a comment, use the normal reply function]
Topic:	How to integrate workflows and QA/LIVE delivery stages?
Forum:	Discussion Group - Web Experience Management
Livelink Server:	knowledge-wlweb01

Markus_Schorer

Hi,

i'll have to clarify:

We do understand the concepts behind the "publishToAllStages" and "publishToSingeStage" sample WFs.

Our question was related to integrating the approval WFs for a ctd and the deployment WF for a site into an overall process:

- we want to go through a series of steps before content is approved

- then "somehow seemlessly" publish to QA, if rejected "unapprove" and send back to approval

- if approved publish to "live"

What we're failing to see is how to split these activities between approval and publishing WFs and "passing info around".

Or, eg in the Sample Workflow:

Should we replace the "Submit for Publishing" activity with "Submit to QA - if OK then SUBMIT TO LIVE else REJECT TO UNAPPROVED" steps? How would the associated "publishing workflow" look like then?

Or should the approval and the publishing be two completely separate processes?

Thnaks,

Markus

Clay Johnson

There really isn’t any formal concept of an “approval”workflow. That’s just the typical implementation of the contenttype default(aka create/update) workflow(s).

The formal concepts are really about triggering mechanisms andpayload;, create/update of an individual item vs publishing one or more itemsto some site. These are treated as separate trigger events so you have theoption to define separate workflows for each purpose. But you don’t have to. Anyworkflow definition, including those configured for these trigger points, canbe modeled to combine whatever behaviors you want.

So it all depends on your business needs. I don’t presume toknow that, but it sounds like you want content create/update to be theinitiation mechanism. And you want the process to involve an approval stepfollowed by publishing that item to one or more stages, possibly withintervening approval steps at each stage. In which case, the site-deploymentworkflow would not necessary be involved. Although if you have similar,multi-stage approval/deployment requirement for manual publish operations formultiple items, then I’d consider developing a subprocess that wouldencapsulate the publishing half, and call that from the create/update workflow. But I think that factoring might obligate you to perform job construction, andit’s not necessary, just a way to keep things modular/consistent ifappropriate.

But if I understand your objective, I’d also suggest taking a lookat custom-automatic publishing. Combined with a content create/update workflowthat performed iterative, stage-by-stage approval, custom-automatic can performthe corresponding stage-by-stage enlistment/publishing part more efficientlythan you are likely to achieve using single-item jobs. The downside is you’dhave to implement some form of stage-specific approval status, but this neednot be complicated. You might just use a couple extended attributes to managethem. You’d need a custom “approve-for-stage” program activity and an IPublishEligibilitiesthat understands these status fields, and you’d have to configure thatIPublishEligibilities for all contenttype(s) you want to participate. It maysound like a lot, but it’s probably no harder than writing fool-proofdeployment workflows and/or job construction programs, and you should get muchbetter performance.

From: eLink Entry: Discussion Group - WebExperience Management [mailto:v7webcontentmanagement@elinkkc.opentext.com]
Sent: Tuesday, July 26, 2011 5:00 AM
To: eLink Recipient
Subject: RE How to integrate workflows and QA/LIVE delivery stages?

RE How to integrate workflows and QA/LIVE delivery stages?

Posted by mschorer@pocketkings.ie (Schorer, Markus) On 2011/07/26 05:56

Hi,

i'll have to clarify:

We do understand the concepts behind the "publishToAllStages" and "publishToSingeStage" sample WFs.

Our question was related to integrating the approval WFs for a ctd and the deployment WF for a site into an overall process:

- we want to go through a series of steps before content is approved

- then "somehow seemlessly" publish to QA, if rejected "unapprove" and send back to approval

- if approved publish to "live"

What we're failing to see is how to split these activities between approval and publishing WFs and "passing info around".

Or, eg in the Sample Workflow:

Should we replace the "Submit for Publishing" activity with "Submit to QA - if OK then SUBMIT TO LIVE else REJECT TO UNAPPROVED" steps? How would the associated "publishing workflow" look like then?

Or should the approval and the ! publishing be two completely separate processes?

Thnaks,

Markus

[To post a comment, use the normal reply function]
Topic:	How to integrate workflows and QA/LIVE delivery stages?
Forum:	Discussion Group - Web Experience Management
Livelink Server:	knowledge-wlweb01

Clay Johnson

Another thing you have to consider when using create/updateworkflows is that the system will trigger the workflow only if the item is notalready in the payload of another (previous) create/update workflow. This avoidsunintended recursion when steps within the process perform updates to itspayload item.

But the flip side of this is you must consider the consequenceof complex/long-lived create/update workflows. For instance, if you implementan iterative, multi-stage approval process as a create/update workflow, oncethat workflow starts, if someone updates the item before it completes, another instanceof that create/update workflow will not be started. So, in effect, you may notbe able to commit multiple versions of an item to the “first” stage, andreceive workflow-driven approval tasks for those commits, while the same itemremains pending at a later stage in a previous workflow. Whether that’s rightor wrong depends.

It’s difficult to prescribe rules that fulfills everyone’srequirements. The suppression mechanism described above prevents recursion whichis usually, but not always, unintended. You can escape this protection bystarting a different workflow from within the create/update workflow. Then thesubsequent workflow can proceed allowing the create/update to complete, soanother create/update can be initiated on the same item. Of course, if that subsequentworkflow updates the item, you can suffer co-recursion between the two that thesystem will not prevent. Generally speaking, you must carefully consider howyou want your processes to behave wrt concurrent activities, and you must designworkflow processes with the same diligence you would use for anygeneral-purpose, concurrent programming environment. This may mean addingconditional logic into the process(es) to control execution depending on the itemstate, including what other processes may already be using it. The api (WfOpsetc) provides access to this.

From: eLink Entry: Discussion Group - WebExperience Management [mailto:v7webcontentmanagement@elinkkc.opentext.com]
Sent: Tuesday, July 26, 2011 4:10 PM
To: eLink Recipient
Subject: RE RE How to integrate workflows and QA/LIVE delivery stages?

RE RE How to integrate workflows and QA/LIVE delivery stages?

Posted by clayj (Johnson, Claiborne) On 2011/07/26 17:09

There really isn’t any formal concept of an “approval” workflow. That’s just the typical implementation of the contenttype default (aka create/update) workflow(s).

The formal concepts are really about triggering mechanisms and payload;, create/update of an individual item vs publishing one or more items to some site. These are treated as separate trigger events so you have the option to define separate workflows for each purpose. But you don’t have to. Any workflow definition, including those configured for these trigger points, can be modeled to combine whatever behaviors you want.

So it all depends on your business needs. I don’t presume to know that, but it sounds like you want content create/update to be the initiation mechanism. And you want the process to involve an approval step followed by publishing that item to one or more stages, possibly with intervening approval steps at each stage. In which case, the site-deployment workflow would not necessary be involved. Although if you have similar, multi-stage approval/deployment requirement for manual publish operations for multiple items, then I’d consider developing a subprocess that would encapsulate the publishing half, and call that from the create/update workflow. But I think that factoring might obligate you to perform job construction, and it’s not necessary, just a way to keep things modular/consistent if appropriate.

But if I understand your objective, I’d also suggest taking a look at custom-automatic publishing. Combined with a content create/update workflow that performed iterative, stage-by-stage approval, custom-automatic can perform the corresponding stage-by-stage enlistment/publishing part more efficiently than you are likely to achieve using single-item jobs. The downside is you’d have to implement some form of stage-specific approval status, but this need not be complicated. You might just use a couple extended attributes to manage them. You’d need a custom “approve-for-stage” program activity and an IPublishEligibilities that understands these status fields, and you’d have to configure that IPublishEligibilities for all contenttype(s) you want to participate. It may sound like a lot, but it’s probably no harder than writing fool-proof deployment workflows and/or job construction programs, and you should get much better performance.

From: eLink Entry: Discussion Group - Web Experience Management [mailto:v7webcontentmanagement@elinkkc.opentext.com]
Sent: Tuesday, July 26, 2011 5:00 AM
To: eLink Recipient
Subject: RE How to integrate workflows and QA/LIVE delivery stages?

RE How to integrate workflows and QA/LIVE delivery stages?

Posted by mschorer@pocketkings.ie (Schorer, Markus) On 2011/07/26 05:56

Hi,

i'll have to clarify:

We do understand the concepts behind the "publishToAllStages" and "publishToSingeStage" sample WFs.

Our question was related to integrating the approval WFs for a ctd and the deployment WF for a site into an overall process:

- we want to go through a series of steps before content is approved

- then "somehow seemlessly" publish to QA, if rejected "unapprove" and send back to approval

- if approved publish to "live"

What we're failing to see is how to split these activities between approval and publishing WFs and "passing info around".

Or, eg in the Sample Workflow:

Should we replace the "Submit for Publishing" activity with "Submit to QA - if OK then SUBMIT TO LIVE else REJECT TO UNAPPROVED" steps? How would the associated "publishing workflow" look like then?

Or should the approval and the ! publishing be two completely separate processes?

Thnaks,

Markus

[To post a comment, use the normal reply function]
Topic:	How to integrate workflows and QA/LIVE delivery stages?
Forum:	Discussion Group - Web Experience Management
Livelink Server:	knowledge-wlweb01

[To post a comment, use the normal reply function]
Topic:	How to integrate workflows and QA/LIVE delivery stages?
Forum:	Discussion Group - Web Experience Management
Livelink Server:	knowledge-wlweb01

Markus_Schorer

Hi Claiborne,

thanks for all your ideas and views - very enlightening to see the whole area covered.

Are there any working demos available (apart from "Sample Workflow")? Further documentation? I've looked at everything in the KB that sounded remotely like "workflow" ...

And demos for creating workflow activities? I already found "wf-ext" - although it's for vignette 7.x.

regards,

markus