Overview

GXS is moving to offer web services interfaces to all of our software and services.

The greatest challenge to the flow of information in a trading community is the large number of information formats and communication protocols. Web services interfaces are a new tool to attack this problem, because they standardize the communications protocol (SOAP) and offer a standard method of describing the information formats (WSDL).

Most GXS technology—especially the solutions we offer as client premises software—works in conjunction with other applications at our clients’ sites. Sometimes data flows to and from our GXS Enterprise Gateway (inbound orders and outbound invoices, for instance), and sometimes the interaction is more complex (bidirectional product data synchronization with our Product Information Manager. Sometimes a solution is used in so many ways—such as our data transformation engine, GXS Application Integrator—that we cannot actually predict how the data will flow.

For this set of challenges, we have created a series of SOAP-based interfaces to our software, to offer a standard technical solution for interacting with our software. Although the capabilities offered vary with the software, the following elements are common:

  • Integrated web services server: GXS products that offer web services interfaces have a “latent” capability to respond to SOAP requests (SOAP specifies a particular message format to send using another protocol. GXS products support HTTP/HTTPS at this time). Basically, this is a special purpose web server that exists only to handle SOAP requests.
  • Access to an underlying security infrastructure: Security is always an issue, and more than one security system for the same data is generally not a good practice, so the web services interfaces accept and use the same credentials as the software they are part of. This means that when you create a new user in GXS Enterprise Gateway, that userid and password may be used to make SOAP requests to the software. This common infrastructure also ensures logging of all activity to the user level.
  • Integration to the Application Layer of the underlying software: The web services interfaces invoke functionality within the application, even when simply querying data. This is critical because application data needs to be accessed and manipulated through the application that owns it, regardless of how the requests are made. Interfaces must be designed as basically an alternative to the user interface (or other interfaces), not as a “back door”.
Benefits

Web Services interfaces generally provide less expensive integration and faster cycle time for development projects, but beyond that, the benefits tend to be specific to a given problem domain. Here are some current examples:

  • Interchange Services Gateway: Provides a SOAP API to work with EDI mailboxes on the GXS Trading Grid. Our very first commercial web services interface, it used the now deprecated SOAP with Attachments standard to allow sending and receiving electronic documents through the GXS Trading Grid.
  • GXS Application Integrator (AI): When equipped with the Web-Services Plug-in, AI is capable of offering translation services via the SOAP interface. Basically, if you have built a "map" (instructions for converting a document of one type into another-often very complex instructions), AI can execute that map as a SOAP request. In addition, AI has an ability to invoke external web services as part of the execution of a data transformation.
  • GXS Product Information Manager (PIM): The GXS PIM software can be equipped with a SOAP interface to make it easier to integrate with a middleware suite for synchronizing product information across an enterprise. Basically, if product information such as "weight" is maintained in one system, that system needs to be able to update GXS PIM whenever the weight of a synchronized item is changed. By offering a web service for updating product data, GXS PIM simplifies this process.
 
What can GXS do for you?
White Papers