documentation tools

[tomkrier]

Just wondering if you have any documentation tools for datapump in progress or beta?

[Gareth Horton]

Tom

I'm not sure exactly what you mean. Are you referring to the stylesheet for the job logs?

Gareth

Originally posted by tomkrier:
Just wondering if you have any documentation tools for datapump in progress or beta?

[tomkrier]

No. They are bugging me to document each "project" (AKA process, usually). So for that they want to see.
-Models that are used
-projects that are used
-files that are need
-when it is sent
-where it is sent to (email, file transfer, ect.)

As we both know all this info is already there and it seems pointless to me to retype it to make someone happy.(which I will probably end up doing) Plus just retyping this data provides a very inaccurate form of documentation. Basically I was wondering if you have and documentations systems (web app. maybe) where anyone can view the jobs, its corresponding models and projects, and all that good stuff they want to view.

[Todd Niemi]

Tom, the log file for each job would provide most of the information they're looking for, I think. You could, for example, via the Job Disposition tab on the Process Properties dialog, specify a distribution that would move the log file of a job that has run to a network folder the people in question have access to.

[Gareth Horton]

Tom

As Todd mentioned, everything is there in the job log, other than the model, but that is documenting after the fact, rather than the Processes/projects them selves.

Maybe a stylesheet for a Data Pump edited project file might be useful?


Gareth

Originally posted by tomkrier:
No. They are bugging me to document each "project" (AKA process, usually). So for that they want to see.
-Models that are used
-projects that are used
-files that are need
-when it is sent
-where it is sent to (email, file transfer, ect.)

As we both know all this info is already there and it seems pointless to me to retype it to make someone happy.(which I will probably end up doing) Plus just retyping this data provides a very inaccurate form of documentation. Basically I was wondering if you have and documentations systems (web app. maybe) where anyone can view the jobs, its corresponding models and projects, and all that good stuff they want to view.

[Joel F]

This is a feature that our company would like to see as well. It would be nice have it exported to a file that could be importing into an Access database so that we could create new tables to add additional documention for each of the processes on Datapump. Things such as what Job creates the input file for datapump, description of why we are using monitoring, etc.

[Ontiveros]

Maybe an update to the Datapump Administrator could have a section under Create, View and Edit Processes that gives show consolidated details regarding all processes (i.e. Input file, output, schedule,log history, etc.).

There could even be a utility created to export a report or text file to a chosen folder or keep an updated log file with process details.

This type of request has been brought up occasionally for at least two years. I know this because I have brought it up on a couple of occasions and unnortunately it is something that has not been listened to.

I am really hoping that this is something Datawatch would seriously consider because it would be very useful in documenting the 100+ processes I use.

[Gareth Horton]

Hi,

This would be a fairly large amount of work to bring all the elements under one roof. Plus, the amount of information would likely not conform to any type of print format.

Currently there are 3 main objects in Data Pump,

Process - Documented only within the User Interface, the data is stored in a SQL Server table as a mix of standard SQL values and an XML data blob.

Project - Self-documenting XML file. This can be viewed via any application, including text editors. Internet Explorer will render the file with a collapsible tree structure. File can be viewed with XPRJ Editor (General Tab|Project Information), supplied with Data Pump, which will show some important information, using an XML Stylesheet inherited from Monarch.

Model - Self-documenting XML file. This can be viewed by any application, inclusing text editors. Internet Explorer will render the file with a collapsible tree structure, File can be viewed with XPRJ Editor (Model Tab|Model Information), which will show some important information, using an XML Stylesheet inherited from Monarch

I am assuming that the item which is the real problem is the Process, since the other elements are self documenting, to an extent, and can be viewed easily.

The schedule is also very transparent, as it uses the Windows Task Scheduler, so you simply need to go to Scheduled Tasks to see them. You can also view them from a remote machine, with sufficient rights.

The log history is also maintained in the Jobs view in Data Pump. If you have not purged/deleted the job, then you can just click on View Log to obtain a self-documenting XML log file. Even if you move the logs, you can still open them with a text editor or Internet Explorer.

There is an enormous amount of information contained within the elements in Data Pump, so if you could put forward your list of the most important items that you would like to see in a single view/page/report etc, I would be grateful.

Gareth

Originally posted by Ontiveros:
Maybe an update to the Datapump Administrator could have a section under Create, View and Edit Processes that gives show consolidated details regarding all processes (i.e. Input file, output, schedule,log history, etc.).

There could even be a utility created to export a report or text file to a chosen folder or keep an updated log file with process details.

This type of request has been brought up occasionally for at least two years. I know this because I have brought it up on a couple of occasions and unnortunately it is something that has not been listened to.

I am really hoping that this is something Datawatch would seriously consider because it would be very useful in documenting the 100+ processes I use.