deciphering the names of log files resulting from workflow executions

Hi everyone! Teamsite newbie here. When running a workflow job, log files are generated. The log files in our installation are stored in C:\Interwoven\OpenDeployNG\log\Livesite. By looking into the different log files and also comparing times, it's possible to figure out which log files correspond to which job executions. Is there an easier way to determine what log files correspond to what job executions? The problem is that the log file names seem pretty cryptic (e.g. src.OpenDeployWebRootgs0ryrrygs0ryrs0.LiveSiteRuntimeDeployment.ksdevts1.to.prod.dev1.ksdevlsprod.kanban.local.log). There's that "gs0ryrry" and "gs0ryrs0" embedded in the name, but I can't figure out what they correspond to. Trying to decode those strings with the assumption that they were base-36 numbers didn't yield anything fruitful. I'm new to Teamsite, so please forgive the lack of clarity in the question, but any light you can shed will be much appreciated.

Thank you!

Find more posts tagged with

Comments

ISCBorisB

src.OpenDeployWebRootgs0ryrrygs0ryrs0.LiveSiteRuntimeDeployment.ksdevts1.to.prod.dev1.ksdevlsprod.kanban.local.log
Let's dissect this a little...

src - fixed prefix of the Source Side Log. Receiver creates it's own logging on the Target side.
OpenDeployWebRootgs0ryrrygs0ryrs0 - Unique Deployment name.
It contains two parts:
   1. OpenDeployWebRoot - Deployment Configuration name.
   2. gs0ryrrygs0ryrs0 - Optional Deployment Instance ID ( -inst key of "iwodcmd start" Command).
   How your process generates it is immaterial. Instances must be unique, that's it. They are
   basically used to allow simultaneous deployments that use the same Configuration.
LiveSiteRuntimeDeployment - Deployment Definition Name within OpenDeployWebRoot Configuration File.
Single Deployment Configuration may have multiple Deployment definitions. Each generates a Log.
ksdevts1 - OD Base Host name
to - fixed Log name element, source/target delimiter.
prod.dev1.ksdevlsprod.kanban.local - Deployment Target Node name. In fan-out Deployment you may have multiple
Target Nodes. Each generates a Log.
log - fixed File extension.

Little self-test: If you have a Deployment Configuration that executes two Deployment Tasks with Definitions D1 and D2
to the Cluster that contains nodes N1, N2 and N3 you should have 2 x 3 = 6 Source Deployments Logs, from "...D1.to.N1.log"
all the way to "...D2.to.N3.log". Makes sense?

Adam Stoller

A little addendum to what Boris posted (which is a great dissection of the OpenDeploy log file naming mechanism) - the log files being talked about there are the deployment "micro logs" - there's also a "macro log" (which does not include source/target pairing information in its name) and the odbase.log (or odrcvr.log) which contains information about the server process itself and not the specific deployments.

All of these are OpenDeploy logs - of importance because the SitePublisher / LiveSite "Publish LiveSite Content" workflow invokes OpenDeploy - they are not workflow logs. The only OOTB logs that specifically monitor workflows are:

Any other log files associated with workflows tend to be custom implementations.

boriskerzner

ISCBorisB - thanks so much for your detailed description of how the log files are named.

ghoti - thanks for giving me your broader comments on OD and workflow log files.

It would seem, then, that it isn't possible to use the workflow id to map to a log file (or set of log files). Are there any other properties of a workflow that can be used to perform this mapping? (Let's assume, for argument's sake, that the set of workflow properties are represented by the getXXX() methods of the com.interwoven.cssdk.workflow.CSWorkflow interface in the CSSDK API.)

nipper

I tend to use either timestamp or grep looking for certain files.

ISCBorisB

It would seem, then, that it isn't possible to use the workflow id to map to a log file (or set of log files)

In my own Deployment Workflows I often use Workflow Id and Deployment Task Id (and sometimes Pass Ordinal number)
to generate Deployment Instance thus creating WF-related naming.

Your problem is that LiveSite Deployments are configured as black (grey, rather) boxes. If you have time to spare
you can dig deeper, find corresponding WF and it's Deployment Task. If Task's source code is available you can
then hack it to modify Instance ID, etc...

Note that as long as you use OD as your Transport, this Instance Id is just about the only thing you can control in
the Deployment naming.

boriskerzner

Hmmm. Let me give that a shot. Thank you Smiley Happy

boriskerzner

nipper - thanks for the suggestion. I might end up going this way.

ISCBorisB - thanks for your comments. Basically, I found that our code calls com.interwoven.livesite.workflow.task.DeploymentTask.deployFiles(TaskContext), but I'm still not sure how to pass my own identifier in (i.e. the one that, if I were running iwodcmd from the command line would be passed in using the -inst flag you mentioned).

boriskerzner

Thanks for your help, ISCBorisB, and let me know, please, if you've got any ideas.

ISCBorisB

Thanks for your help, ISCBorisB, and let me know, please, if you've got any ideas.

Ok, before we discuss any "ideas" let me indicate that if I were you I would not bother.
You must have compelling reasons (some of them you perhaps have not mentioned) to invest
into development that "maps" OD Logs naming to certain WF information. That said, the
way I see it you have few options:

- Develop your own custom deployment implementation Class and do what you want there. This is supported,
see Modeler User's guide for some details. WFM Deployment Task Variable "ClassName" points to the implementation
Class, default is OTB DeployURLExternalTask (your WF may use another one, check the Model). Unfortunately OTB Class
Source is not exposed so you can not use it as a sample (I might be mistaken with that, check with Support).

- Develop your own Deployment Task as external task, URL Task or CGI task and replace WF's OTB Deployment with the
custom one. (Matter of fact, "custom URL Task" option is almost identical to my first proposal, the difference
is mostly in Model, code Class may be the same). This solution is also supported.

- Hack DeployURLExternalTask Class (or whatever you have in your DeploymentTask). This is obviously not supported.
By the same token, you can try to subclass it and override Deployment Method(s). Once again though, all we know
about this stuff is that it perhaps implements "CSURLExternalTask" Interface. Long story short, without Class source or
at least documented API you are on your own.

boriskerzner

Thanks ISCBorisB for your detailed response. There is no urgency around my performing this "mapping". I could always use some kind of "grepping" solution like nipper proposed. I was just hoping to do it "right". I did find the exact location where this id is being set (we're using a de-compiler) and hope to do something like what you suggested in the 3rd step where I subclass, making things behave the way I'd like them to. I'll play with that some more, and if it doesn't work, proceed to hack a "greppy" solution. Thanks!!

Adam Stoller

With regard to overriding or extending the class - you might want to look at this thread