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

Automatic importing and publishing

ttriemst

I have a request to make the following happen, and I would like to know if anyone else has done this and has been successful at it. We have a program that generates a pdf file and places it on our Intranet every hour (we also use WebLogic and are refreshing the content every hour). I was asked to see about moving the process into TeamSite, but I don't know how I would have the pdf imported into TeamSite, and then have an edition published automatically. Once I have the edition published, I can run OpenDeploy (which also starts a pearl script to refresh WebLogic). I need to be able to import the pdf and publish an edition automatically every hour, does anyone have suggestions?

Find more posts tagged with

Comments

iwovGraduate

Heres a suggestion if you want to do everything programatically:

Have you program generate the PDF file to a TS workarea. (Assuming that the program runs on TS server). After the file is generated, the script can run "iwsubmit" command, followed by a "iwpublish" command. See the CLT documentation for usage/flags of these commands. After a successful publish, the script can invoke the OpenDeploy "iwodstart" with appropriate arguments. I would recommend a separate branch/workarea for this.

Note that in this process you are publishing an edition every hour. So the number of editions will grow rapidly unless you have some process that cleans up old editions. In theory there is no limit to the number of editions (in TS 5.5.2), however it *might* be an issue down the road. You can avoid this by deploying the file from STAGING area rather then edition.

Hope that helps.

ttriemst

The problem that I have is that the file (or files in the future) are being generated on another server not related to TeamSite at all. There would be other scripts that would bring the file from another server to my TeamSite server.

You are correct about the edition thing. I have not given it much thought other then how to get the file into the TeamSite.

bman1

OpenDeploy is your friend. If you can spare another OpenDeploy receiver, you could schedule a Reverse Deployment with DNRs before and after. You could even schedule this using the OD Scheduler. The first OD DNR would kick off the pdf generation. Then after the Reverse Deploy, you could run another DNR to Publish and deploy.

If you don't have another OD receiver, buy one, they are cheap. Or you could try sharing/mounting a TS server directory depending on what environment you are in.

iwovGraduate

You can set up ftp between TS and the server where the PDF is generated.
This would be easier if a script from TS server "gets" the file rather then a script from remote server "puts" the file in TS. Either ways, the generation of PDF and the rest of the process would be asynchronous, unless you set up some fancy RPC between the two processes running on different servers.

Alternatively, you can schedule a reverse deployment of the PDF file. In a post deploy DNR script of this deployment you can submit, publish, and invoke another deployment to push it to the final destination.

If the file is not generated in the TS box, it just seems to increase a hop in current process; unless you need to version this file. What is the main reason for doing this using TS/OD ?

ttriemst

We are trying to stick with the use of TS/OD for our Intranet content (except for applications). This helps us to manage what is put out there and to ensure that the content has the same look and feel. We recently redid our Intranet, and the previous one was not very organized. Anyone could put content out there. With TeamSite being the owner (we run UNIX servers), it is a lot more secure and only the gifted have the password.

I like the idea of FTPing the file into the work area, and then running OD to push out the content directly from the workarea rather then publishing an edition. I think everyone answered my questions. Thanks for the ideas.

Adam Stoller

I'd suggest submitting the files and deploying from *staging* not the *workarea* if you're not going to create an edition and deploy from there.

--fish
(Interwoven Senior Technical Consultant)