Structuring Of Packages In The Integration Server Using Webmethods

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
    • Adapters
      • EntireX
      • JDBC
      • NET
    • Documents
    • Internal
      • Documents
      • Services
    • Resources
    • Schemas
    • Services
    • Triggers
    • 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.

Some of our Global Clients