Access external services with HTTP


Hypertext Transfer Protocol (HTTP) binding

Applications using the well-known HTTP web services standard to send and receive messages can access Service Oriented Architecture (SOA) applications developed in IBM Integration Designer with this binding. This binding also permits SOA applications to access web services and other applications using the HTTP protocol.


HTTP binding overview

The HTTP binding is described, which includes a description of its behavior at run time. It is compared with the web services binding.


What is the HTTP binding?

Hypertext Transfer Protocol (HTTP) is a widely-used protocol for transferring information on the web. Though originally designed to publish and retrieve HTML pages, it has now become a standard request/response protocol between clients and server as defined by the HTTP protocol published by the World Wide Web consortium (W3C). Today many standard HTTP methods such as GET, POST, PUT, DELETE and so on are a part of this widely-used protocol.

When working with an external application using the HTTP protocol, an HTTP binding is necessary. The HTTP binding handles the transformation of data passed in as a message in a native format to a business object in a Service Component Architecture-based (SCA) application. The HTTP binding also can transform data passed out as a business object to the native format expected by the external application. for an incoming messaging.


Why has the HTTP binding grown in importance?

As the SOAP/HTTP (referred to as SOAP over HTTP) web services binding gained momentum, businesses began seeing the potential of the HTTP protocol for business needs and application integration. SOAP/HTTP web services became the most common means for business-to-business transactions over the Internet. However, adding more robustness to SOAP/HTTP to suit business needs such as the Web Service Description Language (WSDL), supporting the XML Schema specification and adding Quality of Service (QOS) led to interoperability problems among vendors and additional complexity of the initial specification. It also led to the need for more skills to use SOAP/HTTP.

Users realized there were many situations that did not need the extra functions added to SOAP/HTTP but wanted to take advantage of the ubiquitous web infrastructure to send or receive relatively simple information using the HTTP protocol. They started using HTTP-based services to send and receive data in a set of different loosely-defined formats.

The HTTP binding is suited for this type of user as it combines the ease-of-use and simplicity of the original HTTP protocol with integration to large, scalable and secure SOA applications. Conversely, the HTTP binding allows SOA applications to take advantage of the many existing HTTP-based applications, bringing them into the SOA framework. The binding also provides access from an SOA application to services conforming to the Web 2.0 specification. In summary, the HTTP binding allows applications developed for Process Server to communicate with and mediate between the many web services using HTTP and other protocols, which will make this binding only more important over time.


Comparing the HTTP binding to the web services binding

Another binding, the web services binding, also can be used with applications using the HTTP protocol. The difference between the web services binding and the HTTP binding is as follows:


HTTP binding at run time

In IBM Integration Designer, the HTTP binding can be used on imports and exports.

An import with an HTTP binding at run time sends a request with or without data in the body of the message from the SCA application to the external web service; that is, the request is made from the SCA application to the external web service. Optionally, the import with the HTTP binding may receive data back from the web application in a response to the request.

With an export, the request is made by a client application to a web service. The web service is a web application running on the server. The export is implemented in that web application as a servlet so the client sends its request to a URL address. The servlet passes the request to the SCA application at run time. Optionally, the export may send data to the client application in response to the request.

The interaction style of the HTTP import or export binding is synchronous.



Related concepts:

Uses of the HTTP binding

HTTP data bindings


Related tasks:

Generating an HTTP import binding

Generating an HTTP export binding


Related reference:

Example of the HTTP binding

Limitations of the HTTP binding


Uses of the HTTP binding

The common uses for the HTTP binding with an import, export and function selector are discussed.

The following sections describe the uses of the HTTP binding.


Scenarios for using the HTTP binding

Several common scenarios are used with the HTTP binding.


HTTP import overview

An HTTP import binding lets SCA applications communicate with a wide variety of web applications that provide data in different formats such as XML, SOAP, and binary formats. The number of these services is growing every day as people realize the value of Service Oriented Architecture (SOA) concepts.

This import also makes SCA application to SCA application communication easy and lightweight since the only item that one application needs to know about another is the URL address and the message format. If the HTTP import calls another SCA application using an HTTP export and function selector, the application must also be able to determine the function selector used on the HTTP export. The function selector detects what operation on the interface to invoke once the request is received. For example, if the target HTTP export used a header-based function selector then the HTTP import would need to be configured to provide an operation name in the special HTTP header called TargetFunctionName.

In summary, an HTTP import is a lightweight solution to invoke a remote HTTP service that may provide information in an XML, SOAP or binary format.


HTTP import using a mediation module

A mediation module is used to convert between the interface you want to use and an opaque stream form. With an opaque stream, your application reads a file with no schema specified for it. Define an interface naming the opaque messages for both a request and a response message and define an HTTP import with this interface. You can use a pre-supplied data binding to treat the request and response HTTP messages as stream messages.

Like an HTTP export scenario, the mediation should perform mapping between the two interfaces. Both a request and a response flow would be necessary for a two-way operation


HTTP import using a data binding

It is also possible to invoke an HTTP application directly from an SCA module. In this case, the HTTP import must be configured with appropriate connection information and a custom or supplied data binding, which converts between the interface used by the SCA module and the native format which will be used for HTTP messages.


HTTP export overview

An HTTP export binding lets SCA applications on IBM Business Process Manager or WebSphere Enterprise Service Bus be exposed as an HTTP URL address that can be invoked from the web browser or any other HTTP-enabled web application. Similar to an HTTP import, the HTTP export is a lightweight solution that allows a remote HTTP service to invoke an SCA application and exchange information in an XML, SOAP or binary format


HTTP export using a mediation module

One way to use mediation with respect to an HTTP export would be to build and deploy a separate mediation module, mediating between an HTTP export and an SCA import referencing the BPM service to invoke.

The SCA import would normally be generated by dragging an SCA export from the module the import would invoke to the module that would contain the import. The HTTP export would be configured to use the pre-supplied data bindings in accordance with expected request messages. The function selector would be configured to use the URL context path in combination with an HTTP method used by the request. You would define an interface listing the appropriate pre-supplied type as parameters to both the request and response messages for each exposed operation.

A mediation module would convert request and response messages between this interface and that exported by the SCA module.


HTTP export using a data binding

If the message format is particularly difficult or a mediation module cannot be used then there is an option to write a data binding in Java and use this with an HTTP export. It may be necessary to write two data bindings; one for the request message and one for the response message if these messages will be in different formats.

Your application could make use of the pre-supplied function selector and use the URL context path and HTTP method specified by a request to determine a target operation to invoke.


HTTP export using the pingable function

Some HTTP clients require a validation of the available HTTP export URL before sending requests. This validation is helpful for requests with large payloads. To allow such validation, a user can configure 0 or more HTTP methods as pingable on the HTTP export.


HTTP function selectors

When the HTTP export receives a request message, it uses the function selector to determine the method name that it needs to invoke on the interface based on the HTTP request information.

For a function selector, you can use one of the IBM-supplied function selectors or use a custom function selector. In the second case, you would supply a Java implementation of the FunctionSelector interface.

The supplied HTTP function selectors are as follows:



Related concepts:

HTTP binding overview

HTTP data bindings


Related tasks:

Generating an HTTP import binding

Generating an HTTP export binding


Related reference:

Example of the HTTP binding

Limitations of the HTTP binding


Generating an HTTP import binding

Generate an import with an HTTP binding is shown in this section.

Prerequisite: You should have a module. The module should have an import with an interface.

In this set of steps, you will learn how you create an HTTP binding for an import. This popular protocol is used in many circumstances. It is often used by a web service.

If you intend to use the predefined HTTP bytes data binding then use the following schema and data handler. Under Predefined Resources in the Dependencies editor, select Native Body schema for Native Body DataHandler. Save your work and close the dependencies editor.

If you intend to use the predefined HTTP bytes data binding with a static service gateway then also add the service gateway interface and schema files. To add this interface and schema files to your module, open the dependencies editor. Under Predefined Resources, select Service gateway interface and schema files. Save your work and close the dependencies editor.

  1. Open the assembly editor. Under Outbound Imports, select HTTP and drag it to the assembly editor. Select an interface or create one.

    Alternately, from the palette under Components, select an import and drag it on to the canvas. An import with no implementation and no interface is created. Right-click the import, select Add Interface from the menu and add an interface describing your interaction with a client. Generate the HTTP binding by selecting the import and from the menu selecting Generate Binding > HTTP Binding.

  2. The Configure HTTP Import Service window box opens.

    In the End-point configuration section, enter the Uniform Resource Locator (URL) your binding will request data from.

    In the Default data format field, select how the data will be serialized between the business object and the HTTP message with a binding. To change the default, click Select beside the field to launch the Data Transformation Configuration window. Your selections are as follows:

    In the next section, to use the TargetFunctionName message header property to be used with module to module communication, select it. To use the default module to module fault handling, which is a SOAP transport, select it.

    Click OK. The HTTP binding is created and shown in the properties view when the Binding tab is selected. Sub tabs under the binding tab provide binding information details, which are discussed in the next steps.

    The HTTP binding is complete as is with some qualifications:

    • The interface has only a single operation or, if it has more than one operation, they all use the same URL address.
    • The target service is not using SSL and does not require basic authentication.
    • The request and, if necessary, response does not need to use a proxy.
    • The target service does not need any special headers to be set up.
    • The target service can be called with the default HTTP method preselected by the handler based on the set of assumptions derived from the interface structure.

  3. In the Properties view, selecting the Binding tab displays the service level configuration properties, which can be edited as discussed previously. The endpoint URL and data binding configuration are shown. Note the URL at the method binding level will override this URL.

    The HTTP version and HTTP method, GET by default in a two-way operation and POST in a one-way operation, are shown. The HTTP methods available are: DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE. A description of the binding may be added.

  4. Advanced configuration has the same tabs as described in the next step - HTTP Headers, HTTP Proxy, Security and Performance - but sets the values in these containers at the service level; that is, for the entire service. Method binding properties take precedence over these ones.

  5. Selecting Method bindings and the Generic tab displays the method level properties that can be edited. The properties list the endpoint URL, HTTP method and version and provide a field for a method binding description. These properties only apply to the method level and changing them will only affect the method level, not the entire service. All method level binding properties override the binding level properties.

    In the next section, to use the TargetFunctionName message header property to be used with module to module communication, select it. To use the default module to module fault handling, which is a SOAP transport, select it.

    The Data Serialization tab lets you change the input and output data binding configuration.

    Selecting the HTTP Headers tab lets you choose the transport and content encoding. Defaults are provided, but you can select different types of compression for the content and use chunking for an alternate transfer method. There are a range of media types and character sets that are displayed in drop-down lists. The HTTP 1.1 specification discusses these header fields in detail. The TargetFunctionName header value is displayed. This value corresponds to the operation that should be invoked on the application that is being called by the import.

    Proxy servers service the requests of clients. To use a proxy server, the HTTP Proxy tab presents fields for the host name, port and security attributes.

    The Security tab lets you add an SSL authentication alias and a basic authentication alias. These aliases need to be configured on the server manually to work as they are not created on the deployment of your service.

    The Performance tab lets you set a timeout value and number of retries value to minimize lengthy delays at run time.

  6. Selecting the Faults configuration tab lets you configure the faults specified on the operations in the interface. The configuration of faults is optional. The configuration can apply to all operations or a specific operation.

    If fault configuration is new to you, see Handling faults in bindings for an overview.

    Click Select beside Fault selector to configure a fault. Your selections are as follows:

    Specifying a fault selector requires that you also specify the data format for the fault. Click Select beside Business fault data format . Your selections are as follows:

    Expanding Advanced, lets you also specify the data format for a runtime exception.

  7. The Propagation tab lets you select two types of context propagation. Context propagation takes information associated with a runtime or an application and passes it along with requests that are the result of interactions with that run time or application. The default is to use runtime context propagation. See Propagation.
  8. The Summary page maps a method on the interface to a URL address the application will call when the import is invoked with this method.



Related concepts:

HTTP binding overview

Uses of the HTTP binding

HTTP data bindings


Related tasks:

Generating an HTTP export binding


Related reference:

Example of the HTTP binding

Limitations of the HTTP binding


Generating an HTTP export binding

Generate an export with an HTTP binding is shown in this section.

Prerequisite: You should have a module. The module should have an export with an interface.

In this set of steps, you will learn how you create an HTTP binding for an export. This popular protocol is used in many circumstances. It is often used by a web service.

If you intend to use the predefined HTTP bytes data binding then use the following schema and data handler. Under Predefined Resources in the Dependencies editor, select Native Body schema for Native Body DataHandler. Save your work and close the dependencies editor.

If you intend to use the predefined HTTP bytes data binding with a static service gateway then add the service gateway interface and schema files. To add this interface and schema files to your module, open the dependencies editor. Under Predefined Resources, select Service gateway interface and schema files. Save your work and close the dependencies editor.

  1. Open the assembly editor. Under Inbound Exports, select HTTP and drag it to the assembly editor. Select an interface or create one.

    Alternately, from the palette under Components, select an export and drag it on to the canvas. An export with no implementation and no interface is created. Right-click the export, select Add Interface from the menu and add an interface describing your interaction with a client. Generate the HTTP binding by selecting the export and from the menu selecting Generate Binding > HTTP Binding.

  2. The Configure HTTP Export Service window box opens.

    In the End-point configuration section, enter the context path. By default, it will be the module of your export. The context path is a relative URL address where the application project, <project name>web, is the default context root.

    In the Default data format field, select how the data will be serialized between the business object and the JMS message with a binding. To change the default, click Select beside the field to launch the Data Transformation Configuration window. Your selections are as follows:

    In the Function selector section, select the function selector configuration you want to use. A function selector selects an operation to invoke on your component at run time. Clicking Select beside the Function selector field, launches the Function Selector Configuration window and provides the following selections:

    In the next section, to use the default module to module fault handling, which is a SOAP transport, select it.

    Click OK. The HTTP binding is created and shown in the properties view when the Binding tab is selected. Sub tabs under the binding tab provide binding information details, which are discussed in the next steps.

  3. In the Properties view, selecting the Binding tab displays the service level configuration properties, which can be edited. The context path, function selector configuration and data binding configuration are shown. A description of the binding may be added.
  4. Advanced configuration has the same tabs as described in the next step - HTTP Headers and HTTP Method Settings - but sets the values in these containers at the service level; that is, for the entire service. Method binding properties take precedence over these ones.

  5. Selecting Method bindings and the Generic tab displays the method level properties that can be edited. The properties list the context path and the native method, which will correspond to the operation name of the interface of the export. There is a field for a method binding description. Note these properties only apply to the method level and changing them will only affect the method level, not the entire service. All method binding properties except the context path will be appended to the binding level context path to create a URL pointing to a specific method. All method level binding properties override the binding level properties.

    The Data Serialization tab lets you change the input and output data binding configuration.

    Selecting the HTTP Headers tab lets you choose the transport and content encoding. Defaults are provided, but you can select different types of compression for the content and use chunking for an alternate transfer method. There are a range of media types and character sets that are displayed in drop-down lists. The HTTP 1.1 specification discusses these header fields in detail.

    The HTTP Method Settings tab displays the HTTP methods available. GET is the default for a two-way operation and POST is the default for a one-way operation. The HTTP methods selectable are: DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE. These methods may be set as pingable and also contain a status code. 200, meaning the request sent by the client was successful, is the default status code.

  6. Selecting the Faults configuration tab lets you configure the business fault data format for the faults in the interface. The configuration of faults is optional. The configuration can apply to all operations, a specific operation or a specific fault.

    If fault configuration is new to you, see Handling faults in bindings for an overview.

    Click Select beside Business fault data format . Your selections are as follows:

  7. The Propagation tab lets you select two types of context propagation. Context propagation takes information associated with a runtime or an application and passes it along with requests that are the result of interactions with that run time or application. The default is to use runtime context propagation. See Propagation.
  8. The Summary tab displays the method that will be invoked on the export. The method name defaults to the operation name of the export interface. The endpoint URL address, which is the complete URL for the method, is formed from the application project, <project name>web, interface name and operation name. When the URL specified is invoked, a method with the given name is invoked.



Related concepts:

HTTP binding overview

Uses of the HTTP binding

HTTP data bindings


Related tasks:

Generating an HTTP import binding


Related reference:

Example of the HTTP binding

Limitations of the HTTP binding


Example of the HTTP binding

Applying the HTTP binding to an application is shown in this example.

Creating and configuring HTTP import or HTTP export bindings is not as simple as using a web browser to access data. The article Configure the SCA HTTP binding to enable real-life scenarios on IBM's developerWorks helps you by providing a sample of the most common scenarios involving this binding.

The application demonstrates how HTTP bindings can be used to make the application consumable by HTTP clients, how to consume an external HTTP XML service, and how to integrate SCA application modules using HTTP. For each scenario, specific configuration points are covered. Also shown, are how to create a custom mediation module and a custom data binding with an HTTP binding.


Scenarios shown in the example

The following scenarios are shown in the example:


Description of the example

The goal of the application is to expose an internal data source named Customers (an XML file) to the web using Web 2.0 technologies: a Google map and an Atom feed. To display the customers' locations in this file on the map, a third party REST service, geocoder.ca, is used, which returns the latitude and longitude of any address in the United States and Canada.

Two SCA modules, a library module and a client web application, are created in the example. The library module contains a Web Service Description Language (WSDL) interface and business objects. A CustomerLocations mediation module is used to expose the SCA application through HTTP bindings. The mediation module contains two HTTP export binding components (CustomerLocationsExportAsFeed and CustomerLocationsExportAsXML), a custom mediation component (CustomerLocations) that processes a URL query and forwards the request onward to another SCA component, and an HTTP import binding component (GetCustomersWithLocationsHTTPImport) that invokes the Customers module using HTTP.

The Customers module consists of an HTTP import binding (GetCoordinates) used to invoke the external REST service provided by geocoder.ca. It also includes an HTTP export binding component (GetCustomersWithLocationExport) invoked by the HTTP import binding component from the CustomerLocations mediation module, a simple Java™ component that loads an XML file and returns a list of Customers business objects. The HTTP export binding (AddCustomerExport) is used by an external application to add new Customers to the XML repository by using a POST operation to send an XML file over HTTP. A Business Process Execution Language (BPEL) component (GetCustomersWithLocations) ties the application together by invoking the REST service for each customer retrieved from the XML repository.

The HTTPExportToGoogleMap web project contains an HTML page (customersMap.html) that is designed to create a mashup that displays the customers' locations on the Google map. It also allows the filtering of the Customers that get displayed based on their type.

The application also contains another HTML page (addCustomer.html) that allows a user to add new customers to the data source by invoking an HTTP export binding component through the HTTP POST operation.



Related concepts:

HTTP binding overview

Uses of the HTTP binding

HTTP data bindings


Related tasks:

Generating an HTTP import binding

Generating an HTTP export binding


Related reference:

Limitations of the HTTP binding


Limitations of the HTTP binding

The HTTP binding has the following limitations.


HTTPStreamDataBindingBytes data binding

This data binding requires that a request (and response for a two-way operation) service data object (SDO) be based on the shipped XML Schema Definition (XSD). If the SDO is not based on this XSD, an error is issued during validation. To add this XSD, that is, this business object, to your module, open the dependencies editor. Under Predefined Resources, select Native Body schema for Native Body Datahandler. Save your work and close the dependencies editor. In the navigation view under Data, the business object is listed.


Default content encoding with a POST operation

Default content encoding assumes an XML format is used. In a POST operation, this encoding will cause errors. Specify a non-XML format such as text/plain.



Related concepts:

HTTP binding overview

Uses of the HTTP binding

HTTP data bindings


Related tasks:

Generating an HTTP import binding

Generating an HTTP export binding


Related reference:

Example of the HTTP binding


HTTP data bindings

The data bindings that you can use with the HTTP binding are discussed.



Related concepts:

HTTP binding overview

Uses of the HTTP binding


Related tasks:

Generating an HTTP import binding

Generating an HTTP export binding


Related reference:

Example of the HTTP binding

Limitations of the HTTP binding


Overview of HTTP data bindings

A description of a data binding, how it differs from the HTTP binding presented earlier, the HTTP data format transformations available with BPM and how to develop your own HTTP data format transformation is discussed.

The Hypertext Transfer Protocol (HTTP) is a widely-used protocol for transferring information on the web. It has now become a standard request/response protocol between clients and server as defined by the HTTP protocol published by the World Wide Web consortium (W3C). The HTTP binding discussed earlier supports this protocol. Once you have decided to use HTTP, however, you also need to decide on the data format transformation use with it. The specific HTTP data format transformation chosen is the implementation of the HTTP binding.

The data format transformation takes an incoming stream of data in a native format and converts it to a business object to be used by services created with the service component architecture; for example, data from a Java application to a service created with the Integration Designer editors and wizards. The data format transformation can also take an outgoing stream of data in a business object and convert it to a native format.

The data format transformation can work with a data handler. In this case, the data format transformation delegates the transformation logic to a data handler. The data binding works as a mediator between the transport-dependent protocol, in this case, HTTP, and the transport-independent protocol of the data handler.

In this section, the prepackaged HTTP data format transformations that come with BPM are shown. You are also shown how to develop your own data format transformation using a data handler.



Related concepts:

Prepackaged HTTP data format transformations

Overview of HTTP function selectors

Prepackaged HTTP function selectors


Related reference:

Data handlers

Prepackaged HTTP fault selectors


Prepackaged HTTP data format transformations

A number of HTTP data format transformations are available with BPM.

The following HTTP data format transformations are in the product and can be used with HTTP binding.

If you intend to use the predefined HTTP bytes data binding then use the following schema and data handler. Under Predefined Resources in the Dependencies editor, select Native Body schema for Native Body DataHandler. Save your work and close the Dependencies editor.

Note the wizard shows only the data format transformations available based on the context.

Prepackaged data format transformations

Data format transformations Description Simple type support?
Delimited This data binding serializes the business object to and from a delimited format in the message sent and received from the client. This data binding must be configured. No
Fixed width This data binding serializes the business object to and from a fixed width format in the message sent and received from the client. This data binding must be configured. No
Handled by WTX The data format transformation is delegated to the WebSphere Transformation Extender (WTX). The WTX map name is derived by the data handler. See WTX data handler. No
Handled by WTX Invoker The data format transformation is delegated to the WebSphere Transformation Extender (WTX). The WTX map name is supplied by the user. No
JAXB-based JavaBean This data format transformation serializes JavaBeans to a business object using the Java™ Architecture for XML Binding (JAXB) specification receiving a message and deserializes a business object to a JavaBean using the JAXB specification when sending a message. No
JSON This data format transformation sends and receives a business object based on JavaScript Object Notation (JSON) from the JMS client. This data format transformation must be configured. See JavaScript Object Notation (JSON) format. No
SOAP This data binding parses the body of a SOAP message into a business object in the case of an inbound message and serializes a business object to the body of a SOAP message in the case of an outbound message. Yes
Wrapped bytes This data binding sets the incoming bytes in a business object property called "value" on the inbound message and gets the bytes from the business object property called "value" and sets them in the HTTP output stream. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
Wrapped text This data binding serializes the business object in a message in text for the client. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
UTF8XMLDataHandler This data format transformation parses UTF-8 encoded XML data into a business object when receiving a message. It serializes a business object into UTF-8 encoded XML data when sending a message. Yes



Related concepts:

Overview of HTTP data bindings

Overview of HTTP function selectors

Prepackaged HTTP function selectors


Related reference:

Data handlers

Prepackaged HTTP fault selectors


Data handlers

Data handlers are used when you need a specific data format transformation that is not in the standard set of prepackaged data format transformations.

In effect, data handlers allow you to customize a data format transformation for your particular needs. Data handlers are reusable transformation logic independent of a specific transport protocol, which means you can create a data handler and use it with JMS, MQ, HTTP, EIS and other bindings. Data handlers can be invoked from data bindings and Java™ components.

To learn how to create a data handler, see Data handlers.

To learn how to add a data handler to a data format transformation, see Create a data format transformation resource configuration.





Related concepts:

Prepackaged JMS data format transformations

JMS function selectors

Prepackaged MQ data format transformations

Prepackaged MQ function selectors

Overview of HTTP data bindings

Prepackaged HTTP data format transformations

Overview of HTTP function selectors

Prepackaged HTTP function selectors


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Work with the simple JMS data bindings

Business object XML using JMS text message serialization

Prepackaged JMS and MQ fault selectors

Overview of MQ data format transformations

Overview of the MQ function selectors

Prepackaged HTTP fault selectors


Overview of HTTP function selectors

A function selector determines which operation to call on an export interface.

When the HTTP export receives a request message, it uses the function selector to determine the method name that it needs to invoke on the interface based on the HTTP request information.

For a function selector, you can use one of the IBM-supplied function selectors or use a custom function selector. In the second case, you would supply a Java™ implementation of the FunctionSelector interface.

The supplied HTTP function selectors are as follows:



Related concepts:

Overview of HTTP data bindings

Prepackaged HTTP data format transformations

Prepackaged HTTP function selectors


Related reference:

Data handlers

Prepackaged HTTP fault selectors


Prepackaged HTTP function selectors

Several HTTP function selectors are available with BPM.

The following HTTP function selectors can be used with the HTTP binding.

Note that selections are filtered. If you only had one operation on an interface, for example, then the one operation function selector would be available.

Prepackaged function selectors

Function selector Description
HTTP function selector based on the TargetFunctionName header This function selector uses the TargetFunctionName HTTP header property from the client to determine which operation to invoke at run time from the export.
HTTP function selector based on the URL and HTTP method This function selector uses the relative path from the URL appended with the HTTP method from the client to determine the native operation defined on the export. For example, if the URL is http://www.ibm.com/SampleWeb/SearchFlightInfExport1/findFlight and the HTTP method is GET, then the native method will be /SearchFlightInfExport1/findFlight@get.
HTTP service gateway function selector based on URL with an operation name This function selector should be used in conjunction with an HTTP binding using the service gateway interface. It determines the method to invoke based on the URL and if "operationMode = oneway" has been appended to the request URL.
One operation function selector For an interface with only one operation, this function selector returns the one operation available.



Related concepts:

Overview of HTTP data bindings

Prepackaged HTTP data format transformations

Overview of HTTP function selectors


Related reference:

Data handlers

Prepackaged HTTP fault selectors


Prepackaged HTTP fault selectors

Fault selectors handle runtime exceptions. Some fault selectors come ready to use with the HTTP binding.

You can configure your import and export bindings to handle faults ( business exceptions) that occur during processing. A fault handler can be set up at three levels: you can associate a fault handler with a fault, with an operation, or with a binding. For import bindings, you can also set up a fault selector to determine whether a response is a fault and, if so, the name of the fault. See Handling faults in bindings for more information.

Prepackaged HTTP fault selectors

Fault selectors Description
Header-based fault selector A header-based fault selector examines the headers in the incoming response message to determine if the response message is a business fault, a runtime exception or a normal message.

See Header-based fault selector.

SOAP fault selector A SOAP fault selector examines the body of the incoming response message for the fault message and examines the SOAP header to determine if the fault is a business or runtime fault, and the fault name in the case of a business fault.

See SOAP fault selector.

You can also create a new fault selector resource configuration.



Related concepts:

Overview of HTTP data bindings

Prepackaged HTTP data format transformations

Overview of HTTP function selectors

Prepackaged HTTP function selectors


Related reference:

Data handlers


+

Search Tips   |   Advanced Search