Give us your input!

As we announced at the recent Synergy DevPartner Conference, Synergex will soon be launching a new website, including a new Resource Center. Our goals were to improve the usability of our website and to make it more interactive, engaging, and valuable to the Synergy/DE community. The new Resource Center will include all of the offerings you are used to accessing, plus two new areas: Synergy Answers and Ideas. Answers is a forum for Synergy developers to post questions to the Synergex community and to answer and comment on questions posted by others. It will replace Synergy-l and will offer users a more streamlined and sophisticated experience. Ideas is an exciting new way to submit ideas for improving Synergy products and services to Synergex and the Synergex community and to vote and comment on others’ ideas.

We’re looking for your input! We’ll be rolling out the new Resource Center in multiple phases and are currently testing Phase I. This phase includes the new Answers and Ideas offerings. We’re asking customers to check out the new site and to provide their suggestions. If you are interested in getting a sneak peek and contributing your feedback, please let us know.

Jack Henry & Associates, Inc. (NASDAQ: JKHY) was founded in 1976 as a provider of core information processing solutions for community banks. Today, the company’s extensive array of products and services are processing transactions, automating business processes, and managing mission-critical information for more than 11,900 financial institutions and corporate entities. Their Synergy/DE-based Core Director application is used by over 200 banks. Core Director is a browser-based Windows application that provides point-and-click operation to ensure ease-of-use, maximize staff efficiency and productivity, and expedite initial and ongoing training. The flexible browser UI can easily be customized and modified for every system user.

Jack Henry’s application uses xfServerPlus and xfNetLink .NET to connect with remote logic and data. This solution works great: It allows for data translation between two technologies, and the performance, including ISAM data file access, is excellent. However, having to go through a TCP/IP layer—even on their development machines—has made debugging a challenge.

So at the 2013 Synergy DevPartner Conference, they reached out to Synergex for a solution. “I had a conversation with a Synergex developer and explained to him our debugging challenges,” recalls Senior Software Engineer Nick Hennemann of Jack Henry. “The Synergex developer immediately suggested a Synergy/DE Interop solution.” Synergy/DE Interop is one of the project types available in Synergy DBL Integration for Visual Studio and can be used to convert an xfServerPlus – xfNetLink .NET application into a native .NET application. A Synergy Interop solution would enable Jack Henry to remove the TCP/IP layer from the application and debug their code from beginning to end. And because of Synergy’s tight integration with Visual Studio, the developers would be able to work completely within Visual Studio, with its robust set of debugging tools.

Jack Henry decided to implement this using a two-phased approach, starting with migrating their internal development and maintenance system to a native .NET application. “Our data is not local, so we need to keep the high-performance mechanism provided by xfServerPlus and xfNetLink in place until we can replace it with WCF and remotely kick off methods, which would then be local to the data,” states Hennemann. Because of this approach, Jack Henry’s internal application now runs differently than their production application. Adds Hennemann, “It’s like having the best of both worlds! We can keep all the benefits of communicating via xfServerPlus and xfNetLink for our customers…which affords us lightning fast data retrieval, while being able to use the powerful Visual Studio IDE for developing and maintaining our product.”

The first step was to get their Synergy code .NET-compliant, which included strong prototyping. “At first we were concerned about the effort to do this since we have lots of legacy code,” states Hennemann. “But we realized that doing so would offer us significant future benefits, in addition to the Interop solution. Having our code .NET-compliant will enable us to more readily create Synergy WCF services in the future, something that we are very interested in doing.”

In addition to cleaning up code to make it compatible with .NET, a few other changes are required for an Interop project. These are the same changes you’d need to make to use the dbl2xml utility, which automates the loading of routine metadata into the Synergy Method Catalog. Jack Henry’s developers had already put in the effort several years ago to modify their xfServerPlus routines for use with dbl2xml, but some customers may still need to attribute their xfServerPlus routines, convert structures passed as parameters to structfields, and add direction (IN, OUT, INOUT) and required/optional (REQ, OPT) parameter modifiers. This may seem like a lot of work, but in Jack Henry’s case it will continue to pay off, as it means that they can use the dbl2xml utility to update the SMC for their production application, rather than doing the data entry manually through the Method Definition Utility.

With the phased approach that Jack Henry took, the built-in DBLNET identifier came in very handy, by enabling them to conditionally compile code so that they could work in a hybrid environment. “DBLNET is your friend,” continues Hennemann. “With the DBLNET identifier, you can pick and choose which routines you want to use with .NET. This allows you to get into Interop faster and to make smart decisions in the code with ease. Being able to selectively pick the code that you want to clean up for .NET is vital, as it allows you to start harnessing the power of Visual Studio and Synergy .NET immediately without having to touch every line of code in your application. Over time you can continue to build more and more of your back-end logic into your Interop solution.” Jack Henry’s developers found that DBLNET also allowed them to readily deal with structures passed as parameters in their xfServerPlus routines. All of their structures now reside in a separate .NET DLL, which can simply be referenced. But this meant they had to exclude the .INCLUDE statements for those structures from the code compiled in the Interop solution, which they did with DBLNET.

Jack Henry has completed the migration of their internal system to Synergy .NET Interop and has already experienced significant gains in productivity and quality. “Using an Interop project allows us to readily debug end-to-end—which was the benefit we were initially trying to capture—and find issues much more quickly,” says Hennemann. “But we’ve quickly discovered Interop offers other benefits as well. Not only are we able to develop faster, but the quality of code has improved dramatically. We now have visibility into our back-end code, which was a ‘black box’ before. I highly recommend a Synergy/DE Interop solution to anyone using xfServerPlus and xfNetLink .NET to access data. It will change the way you develop and maintain your product.”

For more information about Synergy/DE Interop projects, see “Converting xfServerPlus routines for native .NET access” in Getting Started with Synergy/DE, or check your Synergy DBL Integration (SDI) online help.

Cause
In 64-bit Windows, the System32 directory is different for 32-bit and 64-bit applications. Because Workbench is a 32-bit application, it doesn’t default to the System32 directory but instead is redirected to one set aside for 32-bit applications.

Solution
When specifying a System32 command in Workbench, you must specify the entire path as C:\WINDOWS\SYSNATIVE. This tells Windows not to redirect your 32-bit application.