Best practices for structuring packages in

webMethods Integration Server

2015-12-30 by Stefan Macke

When I started out implementing services in webMethods Integration Server, I didn’t really
know how to structure my packages. I lacked the experience in what should go where and
which resources are best grouped together. So I ended up with a different folder structure
for all my packages. At this point, finding the resource I wanted to edit was very
cumbersome.

So I asked a Software AG consultant for his recommendation regarding the folder structure
of my packages. And this is what we came up with:

 PackageTemplate
o Adapters
 EntireX
 JDBC
 NET
o Documents
o Internal
 Documents
 Services
o Resources
o Schemas
o Services
o Triggers
o Webservices
I’ve used this structure for quite some time now and I’m pretty happy with it so far. Let me
go into the details on the different folders.

Root Folder
The root folder should be named exactly like the package (hence PackageTemplate).
Although this might seem like redundancy, you need to be aware of the fact, that the
package name is not part of the service namespace! To be able to uniquely identify a
service, you need some kind of fully qualified name. And the package name is not part of
that. So it’s best practice to create a folder with the same name as the package as the root
folder for the package contents. You can then qualify a service like this:
PackageTemplate.MyService.

Public API
The folders Services and Documents represent the package’s public API, i.e. the resources
that are publicly available to every other package and every external consumer. Think of
them like public attributes and methods in Java. This API needs to be stable, because
changing it is expensive and error-prone. Once you publish a service, you’ll never know
who calls it. Therefore, changing the interface later may lead to errors in the consumers.

Private API
The folder Internal contains the private API of the package. This API can be modified as
you like, because there are no external dependencies on it. Think of the services and
documents in their respective subfolders als private methods and attributes in Java. You
can hide the internals of your package by putting them in this structure.

This does not mean, that other packages or consumers are not able to use these resources.
They are not technically hidden from the outside. It’s merely a convention that every
package has to follow and every developer needs to respect (and every architect needs to
enforce 😉 ).

Webservices and REST Resources

Webservices (SOAP and REST) form an additional layer on top of a package’s documents
and services. They only provide another way of accessing the resources through common
interfaces. And they might look quite different from the underlying services (e.g. a POST-
Method might get translated to a simple service call) and follow their own lifecycle.
Therefore, they should be put into their own folders. Webservices contains only Web
Service Descriptors and all REST Resources and their services (_get etc.) are put into
Resources.
Schemas and Triggers
The folders Schemas and Triggers contain their respective resources. Schemas can define
the data structures for multiple services and Triggers implement asynchronous sequences.
These resources play a central role in many packages and need to be taken care of
separately.

Adapters
The folder Adapters contains the package’s different adapter services. For example, in our
case there are adapter services for EntireX, JDBC and .NET. And they are all quite
different from your Flow services, as they need additional Integration Server adapters
installed and integrate external systems into Integration Server. It’s useful to separate those
special services from your own.

What best practices do you follow when structuring your Integration Server packages? Do
you have anything to add to my list?

https://serviceorientedarchitect.com/best-practices-for-structuring-packages-in-webmethods-
integration-server/

Posted By Admin On Wed, May 8, 2019

If you don’t structure tour packages in an efficient manner, it will prove very tedious when
you want to edit the resources. This happens when the software developer doesn’t have the
experience to know which one goes where and invariably he will end up with a different
structure for each of his applications. It is important to group resources together according to
a prescribed plan and if you do so, you will avoid all the pain and effort of searching for what
you want as you go along.

Integrate business processes

When you distribute the packages, you can use the Deployer. By using the web
method integration server, large organizations are able to expose, integrate, and use
business processes including the tools you need to test and deploy new services assemble and
automate services and legacy systems that are loosely assembled. When you need to monitor
the data flow of the Integration server, you use the webMethods Insight.

Package Template structure

You must choose a suitable package structure for your package distribution. The Package
Template will have the following components:

 PackageTemplate
o Adapters
 EntireX
 JDBC
 NET
o Documents
o Internal
 Documents
 Services
o Resources
o Schemas
o Services
o Triggers
o Webservices

It is important to keep the Root Folder with a name that is similar and so we name it
PackageTemplate. The package name here is not a service namespace but the name must be
qualified. So, it is the best practice to name the package using the same on as the root folder.
In which case, you can access the services provided using PackageTemplate.MyService.

Adapters and Public API

The Public API of the package is in the Services and Documents folder. The Adapters enable
external applications to integrate using webMethods. The Adapter Connections, Adapter
Services, and Adapter Notifications make up the Adapters you will use in your system. The
Public API contains all the resources that are available to all other packages publicly and also
to external customers. These resemble the methods and public attributes we use in Java. You
have to make sure the API Is stable because it is an expensive procedure if you need to
change. Further, the process is error-prone.

Enabling instrumentation of the platform

You can use the Directives file to enable default instrumentation for the webmethods
integration server platform. The Folder Internal contains the Private API of the package.
There are no external dependencies on this so you can modify it as you want. You could
consider the documents and services as private attributes and methods in Java. It is possible
to hide internals of your package.

Use of Webservices
After you enable default instrumentation, you can modify default monitoring by customizing
ProbeBuilder directives. REST and SOAP are Webservices that form a top layer over the
documents and services. This is another way you can access resources through common
interfaces. When we view these from the underlying services, they will look different and
have their own lifecycle.

Data structures remain defined by Schemas and it depends on the service you use.
Asynchronous sequences are implemented by Triggers. You need to take care of these
resources separately since they play a central role in many packages.

Leave a Comment

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

http://www.prointegrate.net/blog/structuring-of-packages-in-the-integration-server-using-
webmethods/