PilotFish Interface Exchange (PIE)

A marketplace for eiConsole (IDE) interface templates, components and industry bundles
eiConsole IDE 90-Day Free Trial!
Licensor contacts
Associated Industry
All
Associated Application
Message Testing and Validation
Prerequisites

The XCS eiConsole IDE is required to support graphical development of validations for deployment to the XCS eiPlatform Validation Server

Version
7.11R1
Release Date
June 1, 2011
Resource Type
Core Product

Product details

Validation Server

PilotFish Validation Server enables automating validation and certification of messages to standardize information exchange both initially and ongoing. Companies or standards organizations that are receiving the same message transactions from multiple trading partners or their members can "publish" their own message formats and rules to allow these trading partners or members to test their message transactions before going "live".

Because Validations are configured using the PilotFish XCS eiConsole and deployed to the XCS eiPlatform in the same exact way that interfaces are deployed, users have great flexibility as to the Submission, Validation, and Responses to test their messages. (See details on each below)

How it can be used:

Trade organization have licensed the PilotFish Validation Server to support the automated validation and certification of member messages. Third parties use the Validation server so that they can publish their own message formats and rules and allow their trading partners to test and validate their messages before they go into production. Companies can use the Validation server in the same way to enhance efficiencies with their customers and trading partners. (Custom demos can be arranged to show how the Validation Server would work in your own environment. Call 860-632-9900 Ext. 511).

Submission

The Validation Server can accept incoming "test documents" through a variety of protocols, including but not limited to email, HTTP, HTML Form, and FTP. A trading partner wishing to validate their messages may submit those messages in any of a variety of different ways. For instance, a developer wishing to test a new transaction may alternatively:

  • Send an email with "Transaction Test" in the subject line
  • Post the XML to test.yourcompany.com
  • Select the transaction to be tested from a drop-down on a web page
  • FTP a file to a directory on test.yourcompany.com

Validation

Inbound test documents can be subject to any required validation through a "pluggable" validation architecture. Validation rules can be expressed in XML Schema, Schematron, or in a custom XML validation dialect.

Validation models can be "layered", where a number of different models are applied to the same instance document. For example, the same document may be validated against:

  • The Schema
  • Standards Body Certification Rules
  • Your Company-Specific Implementation Rules
  • Trading Partner-Specific Implementation Rules

This approach also has the benefit of exposing those areas where partners' interpretations are at odds with yours, or with the standard itself.

Response

Validation results can be produced as XML, or as a human-readable HTML report. This report enumerates the rules executed against a particular instance document, the success or failure of the aforementioned rules, and any relevant details in the case of a failure. The report is returned to the submitter through the appropriate transport protocol (email, HTTP, web page, FTP, etc).