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

OD and Workflow

farabi

I would like to configure a WORKFLOW which would be initiated by a custom "publish" button. This workflow would create an edition and then invoke OD to deploy contents to the production servers. Similarly, on a "submit" event a custom workflow invokes OD to deploy contents to the staging servers. We have around 300 users submitting and publishing contents extensively from various branches.

Currently, we have iwat triggers which invoke OD on a "submit" and "publish" event. We want to get away from it due to performance issues. Is WORKFLOW a good workaround? Can mutiple concurrent execution of WORKFLOW cause any issue? Any advice/suggestions will be appreciated.

TS 5.5.2 / OD 5.6

Find more posts tagged with

Comments

nipper

We use WF to push OD hundreds of times per day.

A few points: first make certain you have OD configured to run in parellel, using the -inst flag.

Second, create a filelist and do a filelist deployment. We do not do editions (though hidden ones exists) & I do not know if
that many editions will mean anything.

Finally for every file you create (log, file list, etc) create unique names by appending something like $wf_id to the file name. It prevents collisions and, if you know the WF # then you can find the correct logs easily.

HTH

Andy

Adam Stoller

Out of curiosity - and since there's no information in your profile - for what organization are you working?

I'm curious because I know of one organization which used triggers for submits and publishes as you indicated - but there was a lot more involved with the implementation - and I'd hate for you to find out you're breaking a large chunk of processes by trying to get rid of the trigger-based solution. (of course, if you're not working for the customer I'm thinking of, chances are this isn't an issue and using custom menu items will work - but there's probably more to talk about there too...)

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

farabi

Thanks Andy.
Do you execute the workflows concurrently? Iam wondering if we could have a custom menu which could invoke a workflow. Any thoughts?

Adam Stoller

It's relatively easy to create a custom menu / CGI that will [ultimately] invoke OpenDeploy - though you might just as easily create a simple CGI that redirects to the OpenDeploy Admin UI if you don't need to do any additional work up front. Otherwise you create a CGI form, prompt for the information you need, do some mumbo jumbo and then invoke IWODHOME/bin/iwodcmd start deploymentname [optional flags]

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

nipper

>Do you execute the workflows concurrently? Iam wondering if we could have a custom menu which could
>invoke a workflow. Any thoughts?

Depends on what you need. Do you want the deployment to be part of the submit process ? Then put it at the end of a WF. If this will be an ad hoc depoyment, then you have some choices, use the OD GUI, or create a custom menu item that (optionally creates an edition) and runs OpenDeploy. This is trivial.

BTW, we run our WFs concurrently so it is critical that OD and the scripts be configured to not collide.

Andy

farabi

The expectations from the users is as follows.

The Site owner(s) will submit data in the WORKAREA to the STAGING area using "Submit" option in the file list. At this point of time, the user expects the modified/new data to be deployed to the pre-production servers without any additional effort/activity from him. Similarly, when the site owner "publish" data in TeamSite, he expects the contents to be deployed to the production servers. Currently, it is achived by using iwat triggers for submit/publish event which would execute deployments repectively. We want to get away from triggers due to performance issues.
Iam planning to use the default "submit" workflow to execute OD to move contents to pre-production server. Similarly, create a custom "publish" menu item, which invokes a workflow -> creates edition->executes OD to move data to production servers.

There are mutiple branches accomodating multiple websites. Every site has a site owner. Contents can be submitted/published from any of these sites, at any time of the day and any number of times a day.

Andy,

BTW, we run our WFs concurrently so it is critical that OD and the scripts be configured to not collide.
> I will make certain to have OD configured to run in parallel, using the -inst flag.
Is there anything more that I need to keep in mind?

Fish,
DO you propose to just create a custom menu / CGI and not a WORKFLOW? Did I get you right?

Adam Stoller

Submit is covered by workflow (unless you allow the users access to the Submit Direct option [configurable within iw.cfg on a role-based level])

Publish - well unless you actually have more of a process to take care of than just running iwpublish and initiating a deployment, I think having the custom menu item initiate a workflow is overkill. A CGI could easily do everything it seems you want - and if you code things appropriately you should be able to share code between the custom CGI for publishing and the submit workflow's externaltask or cgitask scripts (i.e. thing designing perl modules to support the deployment semantics and then call the routines in this/these module(s) from your custom CGI script and externaltask/cgitask scripts)

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