Post a Comment On: VismiT

webMethods Integration Server has a specific structure on file system. That is how it will work consistently. It is strongly advised not to change any files without proper understanding and testing. webMethods Integration Server has following folders
auditUsed for Audit store and auditing schemas. binLocation for executables for wM as service configwM configuration files. datastoreService cache data docDocumentation for wM integration server DocumentStoreIS document store. Persisting documents published to IS. jvmDirecotry for JVM, if you are using webMethods provided JVM. libLocation for library files (Jars, dlls etc.) logsLocation for all log files wM creates with all logs. packagesLocation for storing all packages. pipelineDefault location for storing pipelines when you use savePipelineToFile. replicateLocation for incoming or outgoing packages, realases, salvage folders. reposerverLocation for wM Repository server. sdkLocation for wM SDK files, like C or C++ SDKs. supportwM support files to native operations. updateslocation for new realease, which will be included in server classpath. webLocation for wM Tomcat cache. WmRepository2Repository folder. WmRepository4Repository folder.
Under packages folder, IS will be looking for all the packages that are available for execution or activation. Each package has a defined structure. This will also have packages from wM. For example,
codeThis folder has subfolders as code, source and jars. Code is where the comiled class for Java services in that perticular package will be stored. jars is place wher you can include external jars configAny package related config files docDocumentation for the package libExternal/internal libraries for the package manifest.v3Package manifest, loaded into mamory when the package is loaded. nsThis folder has all the code for the pcakege. Except for the java services pubWhere the presentation is stored. Usually all the .dsp files are stored in this folder. .access file determines which file can be accessed from the web front end. Define file/folder and ACL in the file to provide specific accesses. resourcesStill searching what can good use of this folder. templatesAny output templates for the services will be stored in this folder. webThe wMTomcat package uses this folder. Provide the JSP application in this folder that you want to use as the web application under wMTomcat. If there is an application under this folder, the web cache for Tomcat will be in \IntegrationServer\web.
node.idf Under ns folder of your package, you will find the complete structure of the namespace you define in developer. Every package, folder and service will have its own folder. Each folder will have a node.idf file or I would guess something like "interface definition file". This file must be something similar to define that it is another branch. You might sometimes see the node namespace entries there, but still a mystery where that is needed.
node.ndf & flow.xml For each flow service you will find the flow.xml file along with node.ndf. For my reference I use, ndf as "Node Definition File". This is really used to define the node in your name space. They also have the access information, audit information or service level properties that you define in developer. The actual flow.xml file will contain the steps for the flow service. So all the steps you write in a flow service are embeded in sort of the nodes/elements in the flow.xml. You can see that it has some MAP, COMMENT, SEQUENCE and BRANCH as elements. All of these XML nodes are translated in executable code by webMethods in the form of static classes. I believe the way, classes are loaded as static classes, they enhance all the performance. For a wM document, all we have is a node.ndf file. This file will describe the complete structure of the document.
java.frag Every Java service has its own java.frag file. This file is compiled version of the Java service. As we all know, every java service in wM is merely a method in Java class which is named after the folder name where the service resides. This java.frag file in my guess, is only the pointer/redirection to the compiled class under \code\classes folder. If you do not have this file or the .class file, try using jcode.bat file under \IntegrationServer\bin. This will update/compile any java services in the package. We really do not need to modify any of these files, as the developer provides the best way to look at and edit them. They perserve the format which is understood by IS and developer too. This means if we try to edit that outside the standard wM editors, we might loose the consistency.
.cnf files These are mainly the configuration files. Most of the cnf files are stored in \IntegrationServer\config folder. There can be some cnf files in config folder of each webMethods product. This also means that TNConsole or workflow server will have it's specific cnf files. It is possible that each Wm* package under Integration Server also can have its configuration files. These files are loaded in memory when the server, packages, products are loaded in memory and flushed back to file system when these servers, packages, products are shutdown. All the changes in settings of the product are made in memory and flushed only at shutdown. So do not attempt to make changes in those cnf files when the product is running (I would say do not make changes at all in files directly). There are some more cnf files in config\jdbc folder. They are for the JDBC pools of the server. Note: Everytime the IntegrationServer comes up, it backs up all the cnf files in the backup folder.
IntegrationServer\datastore\ServiceCache I believe this file is used to make store the cached the service output. This is an encrypted file, as the data is not much visible in clear text.
IntegrationServer\web\conf\web.xml Most of the web interfaces in IS are managed by integrated Tomcat server. This is needed even for running the WmMonitor. The explicitely created web applications are deployed under the pub folder. At the time of loading that web context the IS creates the compiled classes under web\work\\. This web.xml under conf folder is very similar to one under Jakarta Tomcat server. You can modify the same for servlet mapping, logging configurations, mime-mappings and security constraints of web applications. .access files are also used to define security constraints under each \pub\... folder to define ACLs that are allowed to access the files or subfolders at the same level as the .access file.
Note:
All references made to webMethods products are intellectual property of webMethods. We or webMethods is not responsible for any of the content on this post. All the content on this post is based on merely the observation/experience while working on webMethods platform and must be used, if needed, for supporting, developing on a licensed webMethods product only. The development/support/research made with reference to this post cannot be used as authentic reference or knowledge module anywhere. Nobody can be held responsible including us or webMethods in case of irresponsive system due to changes made with this information.