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

Invoking wft remotely

yshalizi_va

Hello,
How would one invoke a workflow remotely? What would be the best approach to achieving this objective using TS 6.0?

We have a homegrown content management (hgcm) tool and TS/OpenDeploy. We are slowing transitioning the sites into TS but for the interim, we would like to develop an automated content distribution process for the users so they have a simple, efficient process to promote content from the hgcm tool to the production sites. We would like TS/OpenDeploy to manage the content distribution process. In addition, we would like the process invoked from the hgcm server and avoid users’ physically logging in to TeamSite and instantiating the process from the interface. The objective being, we would like to minimize as many manual steps for the user and allow the system to manage it in the backend if at all possible.

If you have any questions, please let me know. Thanks in advance!

Regards,
-Y

Find more posts tagged with

Comments

Adam Stoller

Just to make sure I / we understand what you're trying to do here ...

You want to initiate something from within your hgcm system that will:
(a) import the files into a TeamSite workarea
(b) submit the files into staging
(c) deploy the files to your production system
(d) all of the above without actually physically logging into TeamSite

Is that it? Are you intending to have any kind of review steps take place within TeamSite - or do you just want to begin migrating the content into TeamSite using the hgcm system as the primary "interface" until you've managed to get the entire site transitioned?

The more detail you can provide about the requirements / constraints - the better chance you have of getting a useful response (although frankly, this is the kind of thing I normally would expect to be paid for)

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

yshalizi_va

Adam,
It's good to here from you and I hope you are well!

I wasn't sure if providing details of the process was pertinent to my question but your comments are correct and yes, there will be a few review tasks incorporated in the process. The homegrown tool will identify what has change in the site, (files, database content and so forth), generate a list and provide the list and other parameters to the workflow within the instantiation process so the workflow is aware of what has to be completed. What site to being promoted, if the database should be include, and so on. If further details is required, please let me know.

Regards,
-Y (Yama)

Adam Stoller

If interactions are required in the workflow - then :

we would like the process invoked from the hgcm server and avoid users’ physically logging in to TeamSite and instantiating the process from the interface. can only partially be addressed by having the workflow instantiated automatically, but users will still have to login to the TeamSite UI to interact with the workflow.
There have been a number of threads on instantiating workflows without selecting New Job (or Submit) - and you can probably find the information you're looking for there (some of it depends on which version of TeamSite you are using as to whether certain tools exist).
Next question: Is the hgcm system running on the same server as TeamSite? Or do you need to be able to invoke the workflow on the TeamSite server from a remote system?
If the latter - you will probably have to build your own client/server app to run on the TeamSite server and receive requests ... or possibly use a DNR within OpenDeploy - I.e. run OD to export the content from the hgcm system and import it into the TeamSite system (the mechanics of determining where the assets are to be deployed to, etc. are completely in your ballpark) OD could then run a DNR script (which you create and have located on the TeamSite server) which retrieves information (from the in-memory OD log or it's manifest files perhaps) and then uses that information along with code running locally on the TeamSite server to invoke the workflow (again, the mechanics of how to set all the parameters within the workflow and the design of the workflow process itself - is in your ballpark).

Hope that helps.

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

Driver_Settings.jpg

mgal

Another option is to use cssdk to execute the workflow

yshalizi_va

Thank you...to address a few of your points. The hgcm tool and TeamSite are located on different servers. The only workflow interaction the hgcm site users/administrators will have is when they instantiate the process. This will be accomplished by selecting a 'PROMOTE' button available on the hgcm interface. Once the button is selected, we would like the following to occur:

1. Hgcm tool determines all of the necessary pieces that need to be promoted (database, documents, images).
2. Hgcm tool writes the promotion request details the Hgcm Server database (requests table). The request ID of the new entry will be maintained in order to identify the specific site promotion.
3. Hgcm tool locks the local development site. This will prevent further modifications while the promotion is taking place.
4. Hgcm tool makes a call to a TeamSite script to initiate the Hgcm site promotion workflow passing the following information:
a. REQUEST_ID – The ID given the new entry in the request table of the Hgcm Server database.
b. SITE_FOLDER_NAME – The folder name of the Hgcm site requesting the site promotion.
c. SITE_ADMINISTRATOR_ID – The network User ID of the administrator that requested the site promotion.
d. DOMAIN_INDICATOR – A value to indicate the domain where the site needs to be promoted to.
e. DATABASE_FLAG – A flag to indicate whether or not the database for the site requesting the site promotion needs to be updated.
f. IMAGES – A list of the files that need to be promoted to the images sub-folder.
g. INTERNET_DOCUMENTS – A list of the files that need to be promoted to the docs sub-folder on the Internet production server. This field will be empty when the DOMAIN_INDICTAOR is equal to 2.
h. INTRANET_DOCUMENTS – A list of the files that need to be promoted to the docs sub-folder on the Intranet production server. This field will be empty when the DOMAIN_INDICATOR is equal to 1.
5. The Hgcm site promotion workflow will take the data received from Hgcm tool and move the necessary files.
6. Upon termination of the Hgcm site promotion workflow the TeamSite script will call a script on the Hgcm Server site passing the following information:
a. REQUEST_ID – This is the ID that was passed to the workflow when it was initiated by Hgcm tool.
b. ERROR_CODE – A code to indicate the type of error that was encountered in an unsuccessful site deployment. A value of 0 (zero) indicates that the request was successfully completed.
7. The Hgcm Server script will update the site promotion request in the request table of the database based upon the REQUEST_ID received in the call from the Hgcm site promotion workflow in TeamSite.
a. If the SUCCESS_FLAG is set to True:
i. The entry in the Hgcm Server request table will be marked as completed.
ii. The development site corresponding to the request will be unlocked and the Last Promotion Date/Time field in the configuration table will be updated to the date and time when the administrator originally submitted the site promotion request.
iii. An Email will be sent to the administrator who initiated the request notifying them that their site has been promoted.
b. If the SUCCESS_FLAG is set to False:
i. The entry in the Hgcm Server request table will be marked as deleted.
ii. The development site corresponding to the request will be unlocked.
iii. An Email will be generated to the site administrator who initiated the request notifying them that their site was unable to be promoted. The Email will contain a description based on the ERROR_CODE as to why their site could not be published.

We do have a current process in place similar to what you have described. There are too many manual steps involved for the client and the client has proposed we try to automate most if not all of them.

Regards,
-Y

Adam Stoller

You seem to be changing your statements:
2004-02-27: <font color='brown'>there will be a few review tasks incorporated in the process</font>
2004-03-02: <font color='blue'>The only workflow interaction the hgcm site users/administrators will have is when they instantiate the process.</font>

If you need interaction on the TeamSite side - the users will have to login to TeamSite at some point.
If you do not need interaction on the TeamSite side - you probably don't need a workflow - and you could probably do the entire process with OpenDeploy and a couple of DNR scripts.

It's good that you have a lot of the details / variables figured out - most of what you described sounds like it could be reasonably easily scripted and that a complete implementation could probably be done within 1 month. Not sure what else you're looking for here though.

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

gzevin

hi Yama! how are you doing, man?

yes, I agree with Adam - most likely you'd just need some perl and OpenDeploy..

cheers

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU