A package is a container that is used to bundle services and related elements, such as specifications, webMethods Integration Server document types, webMethods Integration Server schemas, and triggers. When you create a folder, service, webMethods Integration Server document type, or any element, you save it in a package.

The following figure depicts the package structure in a solution.

Packages are designed to hold all of the components of a logical unit in an integration solution. For example, you might group all the services and files specific to a particular marketplace in a single package. All the components that belong to a package reside in the package’s subdirectory.

Services are method-like units of logic that operate on documents. You build services to carry out work such as extracting data from documents, interacting with back-end resources (for example, submitting a query to a database or executing a transaction on a mainframe computer), and publishing documents. Adapters and other add-on packages provide additional services that you use to interact with specific resources or applications. The service editor allows you to view and run the services.

Input and output parameters are the names and types of fields that the service requires as input and generates as output. These parameters are also collectively referred to as a signature. You declare a signature for all types of services: flow services, Java services, and services written in other supported programming languages.

For a flow service, the input side describes the initial contents of the pipeline. In other words, it specifies the variables that this flow service expects to find in the pipeline at run time. The output side identifies the variables produced by the flow service and returned to the pipeline. An webMethods Integration Server document type can also be used to define the input or output parameters for a service.

Click Test to run the service after providing the data to pass into the service.

Use the service editor to view the services. The source code, properties, inputs, and outputs are read only. The editor has the following tabs:

The pipeline is the general term used to refer to the data structure in which input and output values are maintained for a service in Software AG Designer. The pipeline holds the input and output for a service. The pipeline starts with the input to the service and collects inputs and outputs from subsequent services. When a service runs, it has access to all data in the pipeline at that point.

When you run a service in Software AG Designer, you can click Save and save the pipeline data as an XML document to your local file system. After you deploy the service, you can click the Load Data option in the service editor to select the XML file, and load or update the pipeline data to test the service.

After deploying assets, on the Asset explorer page, click the API Details option to view the API details of the service such as the HTTP Method, URL, Input structure, and the parameters that are required to invoke this service from an external system, for example, a REST client. You can copy the required API details to execute the service from the external system.

You will be able to execute a Flat File Schema by using only the SoapUI tool. You must specify the following settings in the SoapUI tool: