LANSA Helps i OS and .NET Apps Meet at Database Level

May 5, 2009 Dan Burger

Application development decisions sometimes come down to bias. That’s a fact. Other times it is a question of skills relating to the particular development task. Sometimes costs, servers, databases, platforms, and interfaces drive the decision. Having options is important and that is why LANSA has introduced a new solution called iFusion.net that combines IBM i and Microsoft technologies. Rather than converting native i applications, it puts the emphasis on building composite applications to gain interoperability.

“We have been driven to this because it is the most common scenario we find with our customers,” says LANSA president Steve Gapp. “The System i is running the larger business applications, and Microsoft is there in different shapes and forms, from servers to small .NET development teams. Typically they are working in silos, and they don’t really talk to one another. There is duplicated data sitting in SQL Server and DB2/400. There is no governance in what is being done. Things are getting worse because of the disconnection.”

That disconnect can be illustrated by a few commonly found scenarios such as an e-commerce Web site built using ASP.NET connected to an IBM i ERP system that publishes up-to-the-second inventory and pricing information along with order processing; the capability to drill down and amend live operational data on the IBM i database directly from a Microsoft Windows- or Web-based dashboard, without having to launch a separate terminal session or window; or providing Microsoft Visual Studio and .NET Framework developers the authority to perform create, read, update and delete actions on the core databases without risk of jeopardizing data integrity or security.

LANSA’s iFusion.net aligns legacy systems with Microsoft solutions like the 2007 Microsoft Office System, SharePoint Server 2007, and SQL Server, or applications built with the .NET Framework. It goes beyond the limits of previous interoperability solutions like refacing, data replication, or file transfer by creating application “mash-ups” that deliver real time enterprise data and functionality to people as they need it.

For the IT manager, this means new applications are delivered faster, and at a lower cost, by reusing existing skills and resources. Application developers can operate without dealing with the idiosyncrasies that the IBM i and Microsoft .NET environments bring to a heterogeneous shop.

Gapp describes the current situation in many IBM System i shops as being made up of two tribes: the IBM i tribe and the Microsoft .NET tribe. The i tribe is in charge of the business applications and they don’t like the .NET tribe making changes to, and potentially corrupting, the relational database. To keep the lid on this simmering pot, LANSA uses controls in its repository that handle data validation and security.

The metadata repository is a services layer that is a key component to application development in the LANSA integrated development environment. It governs all the data constraints, just as it always has, but it has now evolved to include .NET.

The importance of the LANSA repository is chiefly that business rules in the repository are applied to all the connected applications, including those that are running natively on the i and those that are connected via ODBC and JDBC. Development languages that are supported include RPG, COBOL, LANSA, C#, VB.NET, Synon (CA‘s 2E), SQL, and PHP. In this system, everything that touches a file will use repository rules that govern database transactions. This is critical because when a single application (or, God forbid, multiple applications) does not constrain data that all other applications constrain, there well be data integrity issues.

David Brault, LANSA’s product marketing manager, says the data services layer provides is a mechanism to extract all the information about the files in the repository. Those files could be anywhere in the enterprise and could include flat files, packaged and home-grown applications, data warehouse files, data that’s stored in Web services, and documents. Any application designed to extract data has to go through the service layer and be validated. It could be a PHP application, a traditional green-screen application, or a Windows rich-client application. It doesn’t matter what the interface is and doesn’t matter if the connection is made with ODBC, JDBC, or native record-level access.

The importance of the repository being a single location is the differentiator that LANSA emphasizes, because no matter how often the underlying technology changes, there are no changes necessary to the business logic.

LANSA has always had a repository aspect to its development methods. This is where the database is defined and where business logic can be added. It is all done at the database level rather than coding it in the RPG application. In the past, this only applied to LANSA applications.

When a database is put into the LANSA repository–DB2/400, SQL Server, whatever it is–business rules, logic, and validation are enforced by existing applications without changing them, and by .NET applications that are being created.

“We keep talking about the database level,” Brault says. “But what we are talking about is a single point of truth and the information that needs to go into any applications. This is database enforcement and providing a focus on the database rules and logic. We are coming from the software application layer level. We have expanded the way an application can be architected. When viewing the repository, it is possible to see the different data elements throughout the organization. It’s possible to look at all data files and see how they are related to one another.”

Developer skill sets come into play when the business application team is on one page and the user interface and presentation team is on another page. The LANSA repository allows the senior business analysts to define rules and still allows the .NET developers to do what they are good at–creating Windows applications, user friendly interfaces, and easy-to-use presentations.

For example, a company might have a CRM system that runs on Windows, and that system has a lot of customer data sitting in 5250 applications. The typical juggling act has users signing in to a Windows app for CRM, then going to a 5250 app to collect customer data, and then maybe a file server where customer documents are stored. And while that juggling is going on, they are trying to provide help desk service.

LANSA designed iFusion.net to combine the three components and create a better customer service application that quickly finds the customer record, the related documents, then retrieves the CRM info in SQL Server plus the order history in DB2/400.

“That’s not something you can do with a code conversion tool,” claims Gapp. “This is about the CIO deciding that 30 minutes to respond to a customer service call is too long.”

This is much more than making a screen look pretty. In the real world that’s not going to energize an application modernization project.

“Most of our modernization projects have business process improvements in them or they are not going to fly,” Gapp says. “They are not going to get by in this economy. When we talk about modernization, there is an expectation of a Windows or a Web user interface, but that is not good enough. We tend to get into re-architecting what’s going on in the business. It’s about taking 10-step processes down to about two steps. Those types of processes often require some type of fusion between the System i and Microsoft platforms.”

The iFusion.net product is not LANSA’s maiden voyage into Microsoft waters. There have been multiple Microsoft-oriented products along the way. Most recently, during the fall of 2008, LANSA Open for .NET was introduced. It was designed to allow .NET developers to access databases on the System i via the LANSA repository, and it remains a component that sits under the iFusion.net umbrella.

The distinction between Open for .NET and iFusion.net is the capability to set rules at the database level. That, as you now know from reading this article, means other applications (RPG, COBOL. PHP, and the others) that touch these databases will have the same logic and rules applied before allowing any database changes to occur.

The iFusion.net option is another tool in the LANSA shed. And it could turn out to be one of the most used tools, too. There were times when CIOs with a .NET strategy would rule out LANSA. They are in the game now.