Structuring Of Packages In The Integration Server Using Webmethods
By Admin
Wed, May 8, 2019
Updated: Thu, Oct 8, 2026
6 min read
webmethods consulting services
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
- Adapters
- EntireX
- JDBC
- NET
- Documents
- Internal
- Documents
- Services
- Resources
- Schemas
- Services
- Triggers
- Webservices
- Adapters
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.
Frequently Asked Questions
What is a package in webMethods Integration Server?
A package in webMethods Integration Server is a container that groups related resources such as services, documents, schemas, triggers and adapter objects so they can be developed, deployed and managed together. Packages are the unit that developers distribute between Integration Server environments.
Why does package structure matter in webMethods Integration Server?
Package structure matters because an inconsistent layout makes resources hard to find and edit, especially when each developer organizes applications differently. A prescribed structure groups resources by purpose, which saves search time, makes maintenance predictable and helps new team members understand any package in webMethods Integration Server quickly.
What does a recommended webMethods Package Template contain?
The Package Template described for webMethods contains an Adapters folder with subfolders such as EntireX, JDBC and NET, plus Documents, Internal (with its own Documents and Services), Resources, Schemas, Services, Triggers and Webservices. Teams can adapt the exact folders to their projects while keeping the same pattern.
How should I name a webMethods package and its root folder?
Give the package the same name as its root folder, and make the name qualified so it stays unique. In the template example the root folder and package are both named PackageTemplate, so a service is addressed as PackageTemplate.MyService. Consistent naming keeps service references clear across projects.
What is the difference between the public API and the Internal folder in a package?
The public API of a webMethods package sits in its Services and Documents folders and can be used by other packages and external customers, so it should stay stable. The Internal folder holds the private API, which has no external dependencies and can be changed freely, much like private methods in Java.
How do Deployer and webMethods Insight relate to package management?
Deployer is the tool used to distribute packages between environments, while webMethods Insight is used to monitor the data flow of Integration Server. A tidy package structure helps both: it makes deployments easier to assemble and keeps the services being monitored easy to identify.
How do web services and triggers fit into a package structure?
REST and SOAP web services form a layer on top of the documents and services in a package, giving callers a common interface. Triggers implement asynchronous processing, and Schemas define data structures. Because these resources play a central role in many packages, they should be organized and maintained deliberately.
Is it worth restructuring existing webMethods packages?
It can be, but changing a public API is expensive and error-prone, so restructuring needs care. Relevant factors include how many packages depend on the public services, how many teams are involved and how often you change resources. Moving private content inside the Internal folder is usually lower risk than changing public services.
How do I start defining a package standard for webMethods?
Start by agreeing a Package Template with fixed folders and naming rules, then apply it to one new package as a pilot. Document what belongs in the public API and in Internal, and review results with your developers. Pro Integrate offers webMethods consulting services to help set standards.
Does Pro Integrate advise webMethods teams in the US, UK and India on package design?
Yes. Pro Integrate is a global IT consulting company with teams serving clients in the US, UK and India, and can review webMethods package standards with distributed teams across time zones. Reach out through the contact page to discuss your needs.
