Tuesday 6 September 2011

Talking about XML and benefits of using XSD

Some days ago I was contacted from a new friend who introduced me to a new EDI service available here.

I would be glad to say a lot of good stuff about ediFabric but I guess it's better post a small explanation/presentation prepared by the developer him self ! :)

At the moment the service is free of charge so have a look and enjoy !

ediFabric is an integration service to seamlessly describe, translate and collaborate EDI.

Our vision is that EDI definitions and messages can be accurately described using mature and well known format such as XSD.

XSD is used to express a set of rules to which an XML document must conform in order to be considered 'valid' according to that schema.

The apparent benefits of tallying EDI definition and XSD are:

1. Ability to describe EDI definitions using a powerful meta-language, supporting both complex structure and data models.
2. XSD is easy to get into – being one of the major formats used widely to define interfaces, you could easily find any information, samples or tutorials required on the internet.
3. Virtually every software solution or system in the world, which adheres to the latest best practice principles and exposes well defined interfaces, is likely to be naturally XSD friendly. This gives you immediate access to countless number of systems to integrate with.

Having a flexible way to describe EDI definitions is only a part of all features. Adding to the above a flexible parser to convey the conversions is even more impressive.

Parsing from EDI to XML is not a straightforward process. What would be the point of having a static translator, which produces an output you cannot control?

What ediFabric introduces is the concept of a ‘partner’. The partner serves as a separate configuration or instruction set to the underlying parser engine. When you translate an EDI message to XML, the parser engine will check the partner for the following:

- The EDI definition (described with XSD)
- The interchange settings (separator sets, target namespaces, encoding)

The ‘partner’ will influence how the parser translates the same EDI definition. The benefit of this is that you are in complete control of both the EDI definition and the parsing process.

You could for example, have an Edifact INVOIC, parsed in two different ways (either by structure or separator sets) for two different receiver\sender parties. All of that driven by configuration.

ediFabric gives you the tooling to describe and translate EDI messages in a controllable and interface-friendly approach, making communication with other systems easy to establish and support.

It’s hosted in the cloud (currently in Microsoft Azure), and thus offering 99.99% up time as well as it’s scalable enough to handle any increase in load or throughput.

The parsing functionality will be exposed as a web service API’s, to be consumed form various systems or directly from code.

The configuration functionality is available as a web portal at www.edifabric.com, where you can use one of our hundreds EDI definitions (the currently supported formats are Edifact and X12) or construct your own and upload them to your repository. A validation page is provided, where all translations can be quickly tested.

In ediFabric we are determined to deliver a best of breed solution and evolve quickly to meet all our customers’ demands. We will be delighted if you could have a look around and confirm that we have met your expectations.

www.edifabric.com

No comments:

Post a Comment