ProvideX CONNEXION

In FACTS, the value of ProvideX is evident

FACTS is a software solution designed for small and midsized wholesale distributors. You can trace its lineage back the late 1970s when FACTS originally ran on a character-based language called BBx. But in the mid-1990s, the product needed to expand into the GUI environment, which is when INFOR (then Software Solutions) began their relationship with ProvideX. “That was really the key to allowing us to keep the product going and to grow [FACTS] the way we have,” remarks Tim Plotner, senior development manager for INFOR’s distribution group.

But that’s not even half the story. When INFOR initially moved the FACTS product over to ProvideX, the goal was to create a solution where their customers could run either a character or a graphical solution—from one set of source code. “This is where the FACTS architecture grew from,” Plotner pauses, as he gets into the story.

The ProvideX programming interface, NOMADS, could not handle the task at that time, so Plotner’s development team got creative and built their own development environment. “We developed an entirely metadata-based architecture. It allows us to separate the interface from the business logic. The same metadata is used to deliver either a character or a graphical solution.”

This homegrown development environment, combined with ProvideX, helped the company tremendously in several distinct ways:

• Customer-friendly migration! FACTS customers could gradually move to a graphical solution over time.
• More resource bandwidth! The development team could enhance and advance two products (graphical and character versions), while only maintaining one set of source code. This enabled FACTS development to do more without hiring more programmers.
• Customer satisfaction and retention! Because the architecture recognizes and carries customer modifications, customers can avoid the high cost of software upgrades and run more current releases. Customers experience the benefits of new features and are more satisfied overall.

Because they could run any combination of character or graphical interfaces, FACTS customers were given almost 10 years to migrate to the graphical version, spacing out the considerable costs of replacing dumb terminal hardware with PCs, the infrastructure to support the new hardware, system administrator training, and more. Today, INFOR is finally nearing the end of life for their character-based FACTS product. “This architecture was a big competitive advantage for FACTS. Customers weren’t forced to make significant financial decisions and move off the character version. This steady migration has been a big reason we’ve retained so many of our longtime customers,” says Plotner.

Perhaps the most significant contribution of the FACTS architecture is the recent development of the FACTS API Toolkit! This metadata-based tool allows users to quickly define new actions in FACTS through an interface. These actions are actually XML transactions, also known as XML APIs. Instead of having to write a separate program to execute the transaction, the API Toolkit can be mapped directly to existing business logic referenced through the FACTS architecture, and it even honors existing modifications. The FACTS API Toolkit recognizes all the programs in FACTS, and bases any new XML APIs on the same FACTS architecture using the exact same business logic in the metadata.

Leveraging existing code means greater reliability, fewer bugs, and faster times to market. “The same business logic gets executed in the same order in its entirety because the API Toolkit is connected to the FACTS architecture,” confirms Plotner.

And, in a Web-based commerce, the FACTS API Toolkit makes use of the ProvideX Web Server to handle TCP/IP requests and transactions, as well as ProvideX programs.

“Accuracy is more reliable. Bug fixes, enhancements, and customizations can all be modified in one place. And once you do it one place, it’s available everywhere. Whereas without the API Toolkit, you would have to perform modifications in multiple places. You can also rapidly create additional APIs, usually within minutes, because the coding is already done. You just have to create the XML format using the toolkit and it just starts working,” Plotner continues. “But it wouldn’t have been possible to do all of this without the tools and capabilities of ProvideX.”

“I don’t know of another language that would have allowed us the flexibility to do what we’ve done. The ProvideX Web Server is also absolutely critical to this process. Unlike other Web servers, it actually runs our API Toolkit, which is quite amazing,” Plotner says with a chuckle.

“Our ability to create a program based on metadata, almost on the fly, is all due to the ProvideX language. It’s efficient, and the lightening-fast access to the data files is outstanding. In other languages, the overhead of a metadata-based system would offer much slower performance. With ProvideX, we can run hundreds of users with an interpreted language in a derived user interface environment and still have great performance. This is a testament to how powerful the ProvideX language is.”

“I don’t know of any other language that would provide us this type of capabilities with the same performance. It’s quite impressive to think of what we’re doing with our FACTS product, and it’s because the ProvideX language is as powerful as it is,” explains Plotner.

In the near future, INFOR is developing FACTS to run with JavX, a ProvideX tool, which will allow the product to transcend the Windows environment and run on other operating systems, including Linux and Mac. “With the tools that ProvideX offers, it allows us to not only develop an effective solution in terms of performance and programming, but a cost-effective solution. We can play in multiple operating systems and database environments with the same source code. This gives us the ultimate flexibility and it’s a huge advantage,” concludes Plotner.