webMethods File Structure.

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

audit	Used for Audit store and auditing schemas.
bin	Location for executables for wM as service
config	wM configuration files.
datastore	Service cache data
doc	Documentation for wM integration server
DocumentStore	IS document store. Persisting documents published to IS.
jvm	Direcotry for JVM, if you are using webMethods provided JVM.
lib	Location for library files (Jars, dlls etc.)
logs	Location for all log files wM creates with all logs.
packages	Location for storing all packages.
pipeline	Default location for storing pipelines when you use savePipelineToFile.
replicate	Location for incoming or outgoing packages, realases, salvage folders.
reposerver	Location for wM Repository server.
sdk	Location for wM SDK files, like C or C++ SDKs.
support	wM support files to native operations.
updates	location for new realease, which will be included in server classpath.
web	Location for wM Tomcat cache.
WmRepository2	Repository folder.
WmRepository4	Repository 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,

code	This 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
config	Any package related config files
doc	Documentation for the package
lib	External/internal libraries for the package
manifest.v3	Package manifest, loaded into mamory when the package is loaded.
ns	This folder has all the code for the pcakege. Except for the java services
pub	Where 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.
resources	Still searching what can good use of this folder.
templates	Any output templates for the services will be stored in this folder.
web	The 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.

Read Full Story...

webMethods and Microsoft .Net

webMethods 6.1 has opened an interface to Microsoft .Net. This makes it very easier to make calls to components that are very hard to create from Java Runtime. This also allows easier IS client creation from MS.Net. I would not take the client creation as the feature because, anyways it was easier earlier, using InterOps, though by having managed interface, it is now faster than earlier.

webMethods does not allow calling Global Assembly Cache
webMethods can call any service, so the new .Net services can call the .Net assembly classes. The assembly name has to be hard coded in the .Net properties of the service. This makes it further difficult in migration activities. After a considerable research, I could make out that the assembly path can be relative to INTEGRATION_SERVER folder also than using absolute path.

webMethods creates a service for each method selected for interfacing
When creating a .Net service and we need to select assembly, it marks out the classes and their respective methods in the assembly. All selected methods are create a .Net service in the specified folder. So for example, when an assembly has two classses with same procedures/methods with same name, they create a conflict in namespace, so either they have to be in a different logical folder or they have to manually created. This also makes the integration server runtime little heavier I believe, as each method will create a service and then it will be statically loaded in memory when server starts. So it is recommended to create the .Net services for the methods need to be called. I would always avoid calling the .Net service directly, as that will make my application hard to reengineer in case of .Net CLR has performance problems when called from wM.

Every assembly load has a CPU spike
So far I have seen every assembly load, means appdomain load, has a considerable CPU spike. This spike is due to creation of reflection object loading on the CLR. As long as the class lifetime is managed properly, we are cool from infrastucture point of view, other wise .Net usage has to be revisited for the consideration.

Read Full Story...

Changing the webMethods JDBC Adapter Connection

Not sure how many people in software world look around for webMethods help on Internet. Actually, being a google fan, I am used search all the problems and all the knowledge on the Great Internet. Surely tried to search for some solutions on Internet, I got some of them, but not all of them. As we know everything is an node.ndf and/or flow.xml on file system in the little world of webMethods.
Considering the basic fact webMEthods does not support any version control tool integrated with "webMethods Developer". So we have to manage version control for multi developer shop on the basis understanding and coordination. (Offcourse lot of software consultants don;t have that). Then we have more than 3-4 environments and needs to have concurrent development practice. This compelled all around to ding in more and find some way of dynamically creating and destroying local development environments. This allows local development and then uploading that on servers
The compulsion gave rise for the need of using the scripts and or programs to get the automation in place. One of the biggest pain all the time was to modify the JDBC Connections, so that we can script the deployment on webMethods environments.

webMethods uses the JDBC adapter services to connect to databases. As we all know we need to use the JDBC connection defined. This means when we move the code from one environment to other, we have to manually, change connection properties. Scott Conely from ThoughtWorks introduced me to a new way of working with node.ndf files which reside for each service in webMethods.

Every node.ndf file is basically the XML file internally, which stores the information about the service is all about. If you open this with a any XML editor, we can definitely see the data that webMethods needs for its working. This serialized XML element is <value name="IRTNODE_PROPERTY"> which stores the whole serialized object which has information about the JDBC connection. If we could deserialize that object. We can see all the properties of the connection set up from the JDBC Adapters menu of IS Administrator UI. The idea of changing the adapter connection can allow connection manipulation task through scripting. If one can deserialize the data in that element, the changing the connection properties are easier. Then serialize it back and then put that back into node.ndf. Done ... we have modified the node.ndf of connection successfully.

Let see if we can do this. Use com.wm.util.coder.XMLCoder, offcourse gets installed with webMethods installation, to deserialize the element. Basically, this is how it would look loke after the object is deserialized.

>>>BasicData:connectionNodeVersion=1, adapterTypeName=JDBCAdapter, connectionFactoryTypeName= com.wm.adapter.wmjdbc.connection.JDBCConnectionFactory, connectionProperties= >>>BasicData:transactionType=NO_TRANSACTION, datasourceClass= com.microsoft.jdbcx.sqlserver.SQLServerDataSource, serverName=ohclests5337a, user=USER_NAME, password=O/EO8SEgPac=HnSdKdaf6Cs=, databaseName=kpiSchema6, portNumber=1433, networkProtocol=, otherProperties=<<<, connectionManagerProperties= >>>BasicData:poolable=true, minimumPoolSize=1, maximumPoolSize=10, poolIncrementSize=1, blockingTimeout=1000, expireTimeout=1000<<<, connectionEnabled=true, xflds=[0]password<<<

So if you can change these objects and its data elements, the modification is done. Beware when youa re doing it, rememebr that the the whole object you receive is nested IData. if you don't handle this carefully this will spoil the whole connection setup, but who care we can definitely recreate those connections when testing out the program. I did this in Java ... and when I checked with Scott, seems he also did the same way. Finally, Scott showed me something as the password which cannot be modified as it is encrypted in the IData object. Simple solution is change it to new encrypted value, instead of finding encryption. Smart guys ... know how to get the encrypted password before scripting.
Good Luck !!!

Read Full Story...

webMethods 6 Certified Developer

I am primarily a Microsoft Technologies based application developer, the systems based programming interest me more than anything. But due to some recent developments in existing assignment, I have to learn webMethods, which is a fastest growing integration platform. Taking this as an opportunity I passed "webMethods 6 Developer Certification" exam. The exam is online and free tot ake but needs some work experience on the technology.
Being totally Java based immune to convert the ideologies in EAI arena, webMethods can be known more at its advantage website. I will keep on writing more about this technology more and more in future.

Read Full Story...