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

Publishing a single File after publish

waldemar

An interesting Publish "workflow" issue:

During PUBLISH I am generating a file (actually an sql script, generated on the Publish-event) which is written into a special workarea to be submitted into staging and being published again. The goal is to include this single file into the edition the initial publish is generating...

I noticed however, that this file seems to be generated and submitted AFTER all files from the staging are copied into the edition leaving the script one version number behind.

What can I do to include that publish-event triggered file into the current edition?
Maybe there is a special iwpublish that allows to include one single file into an edition? (It seems I have the proper edition name inside an environment variable.)

waldemar
esolut

Find more posts tagged with

Comments

Adam Stoller

A publish event is a snapshot-in-time of the staging area. If you have an event that fires after a publish event occurs (all of the iwat* stuff is *post*-operative) - then by that very definition, you cannot *add* that file to the just-created edition.

The next edition you publish would include that information, but this could cause a nasty cycle of events to occur because the subsequent publish would *also* trigger the post-operative function, and so-on, and so-on.

Is there any way you can generate this SQL script *before* the publish event (within your workflow's externaltask script [presumably] or via a custom menu item to mask out the OOTB Publish menu item?

Without know more about the specifics of the how/why/what/etc of this issue, it's difficult to provide anything more substantial in the way of assistance.

Also - please remember to include TeamSite version information (including patches and service packs) and platform information (OS, etc.) when making posts like this. The answer may be different for different scenarios.

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

waldemar

Thanks for this insight, fish. (This is TS 5.2.2 on W2iK)

>>Without know more about the specifics of the how/why/what/etc of this issue

There is not really more specs on this subject. When somebody clicks Publish, the SQL-Dump will be generated and it needs to go into that very edition...

>> all of the iwat* stuff is *post*-operative
Very valueable information! :-)

So it sounds, this is my two possibilities:

>> Is there any way you can generate this SQL script *before* the publish event (within your workflow's externaltask script [presumably]

I don't see any workflow steps between clicking on publish and the PublishToStagingArea-event... Including that script generation BEFORE the publish wouldn't make any sense because it should have the character of an immediate snapshot just like publish is supposed to be. Or do you have an idea?

>> or via a custom menu item to mask out the OOTB Publish menu item?

This sounds like the only alternative... replacing the Publish-menu-item with that event-script and iwpublish'ing that whole thing afterwards... Is there anything else the built-in publish-function does besides iwpublish?

waldemar
esolut

Adam Stoller

The custom menu item shouldn't be too difficult (requires a bit of CGI coding) - but a question still remains, from where is the SQL dump getting it's information? Is that tied directly to an area within TeamSite, or to an external DB that you just want to dump and store with the edition?

Assuming the latter, the way I'd think about designing the customization would be something like this:
1) Create a temporary workarea using the latest edition (iwlasted CLT) as its base
2) [optional] prompt for an edition name (you can get the default name using the iwnexted CLT)
3) Perform an iwupdate (Get Latest) on the workarea to ensure it is synchronized with STAGING
4) Perform your SQL dump within the workarea
5) Submit the SQL dump file
6) Run the iwpublish CLT

Make sure to track error situations.

Enhance from there.

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

waldemar

Thanks fish, that's the procedure I imagined although I don't understand why to perform an iwupdate (I do have the latest sql file in the workarea since it was just deleted and recreated, beause I am submitting that one directly into staiging, there must also be the latest version)...

streamshare.png

Adam Stoller

It depends on whether or not you can prevent any additional work taking place in the workarea you normally use.

I was assuming a potentially shared workarea, and thus the creation of a temporary workarea whose contents you can control. You base it on the current latest edition, then do an iwupdate to bring it in sync with the files you just submitted, then within that workarea you create your SQL dump file, submit that, and then publish an edition which captures the new SQL dump.

Perhaps I'm missing a nuance here - that was simply my guess at what you could do to accomplish what it sounded to me you were trying to do. Feel free, obviously, to adjust as your needs dictate.

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