- This topic has 11 replies, 7 voices, and was last updated 18 years, 6 months ago by
.
-
Topic
-
Enhancement short description: Separate NetConfig into components
Date:
03/15/2005
Operating System:
AIX
Version of OS:
5.2
Cloverleaf Version:
5.3
Revision:
Rev 2
Tool:
NetConfig
Enhancement Long Description:
A NetConfig that is a directory with config files in it — I have mentioned this before but I would like to see the information for each process in a separate file and the information for each protocol thread in a separate file. This would allow greater automation in the development and maintenance of interfaces.
It might even be nice to have the route/xlate information in a separate file. For example you would have the route information be a keyed list containing the source thread, destination thread, xlate used, tcl proc stack for that route, etc. It might even be better to have separate route directories for each route named according to trxid or something like that. Each trxid directory would then have the route details in files.
The granularity of the file locking would be much better in this hierarchical layout — i.e. you could have several developers working on the same site at once without them interfering with one another. Migration of an individual interface from QA to production would be much more straightforward and implementation would effect just the threads that are involved.
I have a pretty picture of this in my head, but it is hard to describe…
-
Replies
-
-
I like the idea – been struggling with multiple netconfig for some time now. Can’t wait for WDX to implement this, so how about a TCL script that parses the netconfig directory and creates the netconfig file from the directory files. Can’t use the GUI’s to creat or edit them, but it would improve deployment. Would probably need a seperate script to decode a netconfig file into the component parts. hmm, food for thought!
Sven Williams
-
ok .. thought on this a little .. And there really isn’t any reason that someone could create a script to do this .. basically break apart a NetConfig .. and then put it back together.
I’d put it under the
$HCISITEDIR/exec/processes/
/threads/ then have subdirectories for routes (the wild cards could be a challenge)
under the routes, sub directories for each of the dest threads
then .. files containing information on the xlate/raw/generate and pre and post procs.
humm … wouldn’t be all that difficult ..
maybe some day …
Dennis
-
We tried this and it works pretty slick. Unfortunately, I am not at libery to release the code. Our splitter makes separate prologue, process and protocol (thread) files in a netcfg directory. Our ‘mknetcfg’ script puts things back together again, but adjusts port and hostname assignments based on a table. This allows us to migrate more easily from one environment to another (like test to validation to production). I’m still working on fixing directory names for some file-localhost threads. For liability and on-going support reasons, we would like to see Quovadx move forward with this enhancement request. Using customer (or shared) code to modify NetConfig files has some significant drawbacks.
- Mark Thompson
HealthPartners -
For interest sake and a place to start there is some Cloverleaf code out there that loads the NetConfig file into arrays in TCL. Like any of the Cloverleaf undocumented TCL procs you use it at your own risk, we don’t promise not to change anything. The command is nfLoad and it takes several arguments that become array variables. You can find the code in
/tcl/lib/cloverleaf/netData.tlib Here’s a usage snippet:
global HciSiteDir
set fsNetconfig [file join $HciSiteDir NetConfig]
nfLoad $fsNetconfig aProcData aConnData aXltData klPrologue
set procNames [array names aProcData]
# get the process data for the first process in the list
set procData [array get aProcData [lindex $procNames 0]]
-
-
-
We developed a web base tool to view all our interfaces (+850) and started adding some comments about the interfaces. We ended with more than just one comment field per interface. Some of the info that we store is: – Application name, server location, platform
– Contact name and support phone/pager
– Facility (we have about 20)
– How critical it is (from “page now”, to “wait until Monday morning”)
– Description of the interface, special procedures, business reason, etc.
– List of monitoring jobs (customized to each thread)
We started to send events to Tivoli
-
How about adding a new selection to the NetMonitor’s right-click (on thread or process) where we can choose a hotlink to whatever documentation suits our needs? These hotlinks could be added via NetConfig for the threads. They could point to .html, .doc, or .ppt files. The format is left to the customer. This would satisfy the need to describe anything you’d like about the thread (application, server, vendor, contacts, twists, gotchas, etc…).
I would begin with reference to instructions for cycling the other side of the connection… the application’s
Interface Agent… for use by the OPS staff or HelpDesk. I’d create an html “home page” for each application. From each “home” there would be various additional links to each area of interest for that thread. Multiple threads for a single application could have links on their respective “homes” to a common “application info” page, etc…
I’d need to think about what to document on the hotlinks for PROCS. I guess this would depend on the design of your engine.
-
-
-
I was the “guest” that started this thread. Since then I have done a lot more with the NetConfig Load command and I agree with the other posts that talk about tools for splitting apart the NetConfig into its requisite pieces regardless of whether the functionality is implemented into cloverleaf itself. That said, I can do the TCL to accomplish that. For any interested parties that are not aware of it, the NetConfig Load command loads the NetConfig file into the interpreter and makes available a bunch of VERY handy commands for messing around with it. Do an “info commands net*”. If you have not done this before, you will find out that all that parsing of the NetConfig that you have been wanting to do has already been done. As Rey Currie points out in more than one post, use this at your own risk because the functionality is subject to change.
On that same note, there are some very interesting things available out in the $HCIROOT/tcl/lib/ directory structure, check them out. There is a BounceSite that works great and many other neat little toys. I will warn you, though, that “out of the box” some of them do not work. This is because the #! line in the perl scripts in $HCIROOT/bin have a space after the word perl. You will get an error saying “Can’t find ‘perl ‘” when you try to run them. Carefully going through those perl scripts and taking out that space will make them work. PLEASE MAKE BACKUP COPIES BEFORE YOU DO THIS!!!!
Now a couple of rants for good measure.
1. Why in the world is there a space after that perl command?
2. Why does the release code have lines in it containing the following?
/work2/jerickso/quovadx_dev/qdx5.3P/integrator
I feel somewhat bad in that I don’t even know how jerickso is but I find myself not being particularly fond of this person…lol.
Well, back to work…have a good day all!
-
- The forum ‘Product Enhancements’ is closed to new topics and replies.
