Coding Guidelines in webMethods IS – Part 2

Package guidelines

Connections package


The connections related to a certain interface should have their own package and mixing them with other assets should be avoided.

One of the main benefits of this approach is that changes to the assets can be deployed without affecting the connections.

You can go also one step further: separate the connections by connection type (JDBC connections, SAP connections, etc) in different packages.

This approach helps when setting dependencies, as one implementation (package) might require only the JDBC or only the SAP connection.



Documents package


What is valid for connections is valid for document type definitions as well.

The document types should reside in a standalone package. This is important especially if you have a canonical data model with a plethora of document type definitions.

The reason is simple: the documents will change rarely, so there is no added value to deploy them every time the other assets change.



Unauthorized Access and Orphan services


Every package should have a public API. Often this is represented by the services in the pub folder. This should be the only entry point in the package. Services outside the package should not be able to invoke services that are not part of the API.

Every service from a package should be used directly or indirectly from the public API or from one of the package’s DSP files.

If the above is not respected it can mean one of two things:

  • the service is not used and therefore can be removed or
  • the service is used from outside the package, hence there is an unauthorized access.

Like any good rule, it has exceptions and utility packages are the most popular exception. These packages can have services that are not, yet, invoked from other services.

The utility services are, by definition, public and therefore should be present in folders beneath the pub folder. A very good example here is the WmPublic package.



WmRoot services


Have you ever did an IS configuration from the admin console and thought: “Gee, I would really like to do this programmatically or put in a startup service or…”

Well, there are some good news and bad news.

Good news: Most configurations that you do from the admin console have a service counterpart. For the majority of these the service is located in the WmRoot package.

Bad news: You should not use services from the WmRoot package because these are internal SAG services that can change without notice.

The WmRoot package is by default set as invisible after Integration Server installation (watt.server.ns.hideWmRoot=true). I would leave it like this.



Package dependencies


This rule can get you out of a lot of trouble. Strangely enough, I do not see it applied that often.

What is a package dependency? Well, it is a statement that assets from a package depend upon assets from another package.



That’s all you have to do. Set it up. IS will do the rest, i.e load the packages in the correct order.

A package that has dependencies on another package cannot be loaded before it.

Cases when it is proper to setup dependencies:

  • when a startup service from one package calls services from another package.
  • when a service uses a document type from a different package in the input or output signature.
  • when a Web Service Provider uses document types from another package. If a package dependency is not used, at startup IS will not be able to enable the WS interface.
  • when Java services in a package use Java classes contained in another package.
  • A package that has adapter services must depend on the corresponding connection package.



Important: Do not. I repeat. Do not create circular package dependencies. If you do this neither of the involved packages will load the next time you start the Integration Server.

If Package A depends on Package B, make sure that Package B does not depend on Package A.


When creating a dependency you can specify the exact version on which the package depends.

However, it is better to not do it and just use * for Version.

Only one version of a package can be installed at one point. If you specify a version and it is not the correct one, Integration Server does not load the dependent package.



I hope you found some value in this blog post and I hope it will help you when defining and structuring your packages and services.

Do you think I might have forgotten something about package and service guidelines? Comment below and let me know.

Til next time when we will dive deep into the service to see STEP (MAP, BRANCH, etc..) guidelines, I wish you happy exploring.


Your friendly neighborhood explorer,


4 thoughts on “Coding Guidelines in webMethods IS – Part 2

  • casualreader

    > Services that constitute the public API of a package must have a try-catch block to ensure the graceful handling of error conditions when they occur

    This is a wrong approach IMO. Better let the caller deal with it.

    • On this topic we have to agree to disagree. Although letting the caller deal with the exception scenarios is appealing it is not a good idea.

      Having the try catch block in your public API gives you the control of what is returned to the caller.

      You might want to return just one type of exception for all tech problems, for example.

      Also you can decide in the catch block what exactly handling means: logging, repair attempt, etc..

      And I would say that a great benefit of having the try catch in your public API is that the caller is not burdened with low level (ex: DB) exceptions.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: