XML and FileMaker Pro 6 in the Real World

by Russell Kohn
Chaparral Software & Consulting Services, Inc.

After years of hype about the technology, and much focus on the bits and the bytes, what are the real business imperatives that can be addressed, in the real world, with the "XML thing", where client organizations can make money, save money, and therefore be willing to pay money?

1. Loose Integration with the Microsoft Office Suite.
2. Co-existence with .NET.
3. Leverage XML data sources.

1. Loose Integration with the Microsoft Office Suite

As the Office suite becomes more and more XML savvy, the possibilities for exchanging data between Office and FMP are staggering. Currently, without XML, such integration is what I refer to as "tightly coupled", meaning you need to set up (generally) a very specific series of ODBC connections, VBA code within documents etc. that are harder to build, deploy and maintain than what XML offers (though they can be very powerful and definitely still have a place). Applications that I can see now in this area include:

• Using Word as a rendering engine for document types that are hard to format in FileMaker. For example, a multi-column text section within a larger document with merge fields throughout, or a customer-modifiable mail-merge-letter without having to worry about page breaks.
  
• Using FMP as a document management system to automate the production of MS Word files, where all the Word Properties are automatically filled out.
  
• Migrating data to and from Excel much more conveniently with less (or no) code changes required in either FMP or Excel core code.

Client Benefits

• Data in FMP is more accurate as more group data is maintained in a controlled fashion in FMP-based database (where it belongs) rather than in office-suite documents.
• Common Office documents can be more quickly created, with a more common look & feel, without custom programming required in every instance.
  
• Near-zero deployment costs. A change in the database or the Office template need not require changes in the other. For example, let's say a Word document template needs to be updated. Instead of deploying that to every workstation and relinking the FMP script and testing paths etc., simply replace the corresponding XSLT document, which is probably located on an HTTP server within the office, and everyone immediately gets the new version.

2. Co-existence with .NET

According to Microsoft: XML Web Services are units of code that allow programs written in different programming languages and on different platforms to communicate and share data through standard Internet protocalls such as, XML, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discover, and Integration (UDDI). (http://www.microsoft.com/net/business/it_pros.asp)

Given the momentum of the .NET initiative, I think we can count on there being lots of "web services" coming onto the market. What does this mean to us and our clients?

Since FMP6 can read and write XML, this will not be a problem. Existing and future FMP-based solutions will be able to communicate with these other systems.

Client Benefits

• Systems built in FMP need not be rebuilt in .NET to work with .NET
• Clients can relax and ignore FUD ("fear, uncertainty, and doubt") marketing knowing that XML can be integrated into FMP when they need it to be...they will not be stuck on a data island.

3. Leverage XML data sources

Given the investment in XML by Microsoft, Oracle, and IBM in their database units, and predictions of XML storage in these database products reaching perhaps 25% of total application usage within the next few years, it is safe to assume that XML as a data type is indeed here to stay. (http://www.zapthink.com) More and more, we will see XML files, data streams, and sources coming from many different places.

For any given industry, we can expect there to probably be some competition between several providers of key data, and differences in the way they provide that data.

To the extent our clients want to use this industry specific data, wouldn't it be nice if we didn't need to rev our core FMP code every time a data source was added or format changed?

With XML support, we can build structures into FMP based solutions that anticipate multiple data sources. We'll need to modify an XSLT document to map that source to our way of handling the data internally, but that's it. Deployment across an entire user base is accomplished via an email with the XSLT attachment and a few words of instruction regarding where to put it on their server.

Clients can seamlessly see new data flowing into existing FMP systems without requiring a major conversion & import/export cycle.

Clients who publish data to others can similarly become a data publisher if they so desire, and possibly gain market share by the quality and consistency of their data.

Client Benefits

• Flexible and loose integration with outside data sources
• Quickly adapt and take advantage of new information should provide competitive edge
• Less costly to integrate any single datasource once structures are in place
• Some industries are going to require xml integration