.NET Abides by IBM i Logic, Thanks to New LANSA Product

September 23, 2008 Alex Woodie

It would be a huge understatement to say it’s a challenge to get .NET and RPG programs–let alone .NET or RPG programmers–to play by the same set of rules. For companies that rely on a mix of IBM i (AS/400) and Microsoft Windows servers to run their business applications, it’s a problem faced on a daily basis. But thanks to a new data integrity tool launched last week, LANSA‘s Open for .NET, users can share DB2/400 data and enforce IBM i business rules upon Windows .NET applications, in real time.

The development of different and unique “silos” of data, skills, and technology is an age-old problem afflicting practically all organizations that have invested in IT. Of course, these organizations didn’t intend to create these separate and largely unmixable collections. It just happened that way, as organizations adopted different IT technologies over the years to address then-current business problems.

In the case of many AS/400 shops, the Windows platform is home to the largest non-AS/400 silo of data, skills, and technology. In many ways, the relationship is symbiotic, with the big IBM iron providing the rock-solid, back-end data processing, and the ubiquitous Windows PC serving up glamorous graphical interfaces with nifty point-and-click user interaction.

But when it comes to server-to-server interaction between the AS/400s and the Windows servers, the relationship is not as pretty. Many techniques have been devised to smooth over the differences between an IBM i-based ERP application and, say, a Windows-based e-commerce Web site. The open database connectivity (ODBC) standard is perhaps the most common way to share data between the two platforms. When ODBC connectivity is too cumbersome and slow (as it is for many AS/400 shops), the use of IBM APIs can provide native, record-level access to the AS/400. However, correctly implementing the IBM API is easier said than done. Tools are also available to synchronize entire databases, but that’s not ideal for processing real-time transactions.

That’s where LANSA and its new LANSA Open for .NET product come in. Instead of relying upon unreliable and insecure ODBC connections, complicated APIs, or cumbersome database synchronization tools, Visual Studio programmers can insert this new product into their .NET code, and let DB2/400 handle the heavy-duty data processing and validation activities that it’s so good at providing.

LANSA Open for .NET consists of a class library for Visual Studio, and a scaled-down version of the full LANSA development repository that can exist on the Windows or IBM i server. As programmers develop their .NET applications in their Visual Studio language of choice (like VB.net or C#), instead of manually coding in business rules (such as address validation or credit check routines), they simply refer to the LANSA Open for .NET class library, which in turn establishes a secure, record-level connection to DB2/400 and feeds data back to the Windows application in real time.

Among the benefits of the new tool are tighter security, faster performance, and–perhaps most importantly–cleaner and more reliable data, says David Brault, product marketing manager with LANSA. “What we’re finding is, as [customers] start to have these extended applications become more distributed and, more importantly, more transactional, it’s becoming more apparent that they need to have some sort of proper data services layer somewhere in their system architecture,” he says.

The new software will eliminate some of the problems stemming from the need to maintain the integrity of data, which are often coded using validation routines and constraints in RPG, COBOL, or DB2/400 itself. “Some organizations will have different data constraints and validations for the same file located throughout their programs,” Brault says. “As business rules change, they have to go through all their RPG and .NET applications. Hopefully they don’t miss one, but every once in a while, they do miss one. So suddenly they’re going to have data integrity issues, because one application cannot constrain the data like all the other applications are.”

Due to this problem, some organizations don’t even bother trying to automate the integration of their data, Brault says. “What they do is re-key data from their .NET applications into the 5250 interface to try and reuse some of the business logic that’s already in place,” he says. “But now they need to worry about keying errors.”

Organizations can avoid this fate by using LANSA Open for .NET to store all of their business rules for i OS and .NET applications–or at least the business rules for the new applications.

LANSA recognizes it needs to be pragmatic about its approach. “We understand right off the bat that you’re not going to be able to go through all RPG programs and pull out all your source code and let the LANSA repository handle it,” Brault says. “What we’re suggesting is, as you start to build these .NET programs, instead of putting that code in your .NET source code, put it in your LANSA repository. Yes, there will be a time when you need to maintain two sets of business rules, one in the RPG logic and one in the repository. But as time goes on, instead of going through 50 RPG programs to make that change . . . you pull out that code and let the repository take over.”

Of course, customers could get the same benefit (and more!) by standardizing all of their development on the LANSA fourth-generation language environment. But again, LANSA’s pragmatism shows with LANSA Open for .NET. “If we can’t get them to buy off on that [the full LANSA IDE], this is a follow-up product,” Brault says. “We understand you have this problem duplicating code between these two environments. Here’s a way to eliminate that.”

Version 1.0 of LANSA Open for .NET is available now. Pricing is tier-based and ranges roughly from $5,000 to about $30,000; contact the vendor for exact pricing. For more information, visit LANSA’s Web site at www.lansa.com.