This article originally published in the Architects Corner section of our LANSA Review customer magazine Issue 37, 2008.
Combining data from IBM i and Microsoft Windows can be a difficult undertaking, as it requires knowledge of both. There are a number of products available that claim to narrow the gap between the IBM i and Windows platforms, such as 5250 emulators, screen scrapers and ODBC/JDBC data access tools.
Platform divide still a challenge
The problem is that these products only narrow parts of the gap. After having the two platforms running side-by-side for over two decades, many IT managers are still challenged managing the platform divide. For example, how can you be assured that the same rules apply when a .NET program and an RPG program both update a database?
What we need is an effective mechanism for mixed development environments to share resources. We need a tool that bridges the gap completely.
Companies that need to develop with .NET tools and incorporate resources from the IBM i can do so with LANSA Open for .NET.
What is LANSA Open for .NET?
LANSA Open for .NET is a class library. The class library exposes services (including data and programs) that .NET developers can incorporate into Windows rich client and Web applications. The class library DLL is deployed with the .NET application.
Using LANSA Open for .NET and C#.NET, you can write a Web service to act as a gateway to RPG, COBOL, Java and LANSA applications on the IBM i and the DB2 database. With this architecture, any application that can consume the Web service has access to resources on an IBM i server. For example you can:
- Write C# or VB.NET programs that access data and programs on the IBM i server without leaving Visual Studio.
- Create and publish Web services from the IBM i server.
LANSA Open for .NET overcomes the challenge of bridging different architectures and simplifies the management of siloed development teams. Windows developers can write .NET applications and take advantage of resources on the IBM i server without leaving Visual Studio. The .NET applications do not need to implement a duplicate set of business rules. Defining and applying business rules from a central point is particularly advantageous for Windows rich-client applications, as the rules can change without the need to recompile or redeploy the client components of the application. The rules are defined in the central LANSA Repository.
.NET applications and LANSA Open for .NET
Here are some of the situations where you can use LANSA Open for .NET:
- Retrieve data from DB2 databases on the IBM i server.
- Perform create, update, insert, delete operations against DB2 databases, applying the same business rules as your IBM i applications would apply, without having to duplicate the rules in your .NET environment and without having to recompile .NET programs when the rules change.
- Invoke programs on the IBM i server, including LANSA functions and programs written in RPG, COBOL or Java.
- Access information in the LANSA Repository, such as formula fields, multilingual definitions, help text, file definitions and field definitions.
Scenario #1 Browser-based ASP.NET Web application working with an RPG application on an IBM i server.
Suppose a company wants to improve customer service and reduce the volume of inquiry calls by providing customers with Web self-service access to their orders. The manufacturer's ERP package on the IBM i provides a 5250 screen for order enquiry that is inappropriate for the Web context.
As the company's policy is to deliver their Web sites via Windows servers, they decide to build an ASP.NET Web application that will extract information from the ERP system on the IBM i, using LANSA Open for .NET.
Because the ERP system is not a LANSA application, the database definitions associated with orders have to be 'made known' to the LANSA Repository. This process is automated. In addition, formula fields, validations and other business rules can be added to the LANSA Repository without affecting the ERP system itself. The LANSA Open for .NET DLL will publish the table definitions for use by the ASP.NET Web application.
The .NET developer only has to build the ASP.NET Web application and pass calls to the LANSA Open for .NET DLL.
Suppose the company wants to give customers the option to update their ship-to details. The optimum approach is to define the validation rules in the LANSA Repository. LANSA applies the validation rules and returns any error messages, which LANSA Open for .NET passes back to the ASP.NET application. The ASP.NET Web application only needs minor change and an exception handler to display possible error messages.
Validation rules can be changed without having to recompile or redeploy the ASP.NET Web application.
Scenario #2 Rich-client .NET application working with a LANSA application on an IBM i server.
Suppose a company wants to grant its sales people update access to the customer details. The Customer Management System (CMS) resides on the IBM i and is written in LANSA, so the business rules governing the CMS already reside in the LANSA Repository.
The company decides to build a rich-client .NET application written in C# to deploy to the sales people's laptops and notebooks. Through LANSA Open for .NET, the .NET developer will see the CMS as if it were another .NET application. LANSA enforces the business rules and any errors will be returned to the .NET application via LANSA Open for .NET.
This solution reuses the existing CMS, hides the architecture differences and ensures data integrity.
Web services and LANSA Open for .NET
The Web service is a C#.NET program which uses LANSA Open for .NET to access data and programs on the IBM i server. For example, the Web service can provide customer data from a DB2 database to a Windows-based Web application. The Web application will call the Web service to request customer details. The Web service will invoke LANSA Open for.NET to retrieve the data and then return the customer details to the Web application.
The Web service will be a simple program that acts as a mediator to manage the requests and responses. LANSA Open for .NET and the LANSA application do the real work by applying the business rules and retrieving (or updating) the DB2 data.
This architecture applies to situations where you need to incorporate data or other IBM i resources into an application. Typically, the application consuming the Web service will manage the user interface and will use the Web services to supply data or to initiate an activity on a remote system.
LANSA Open for .NET simplifies the transformation of resources on an IBM i server into Web services.
Scenario #3 Microsoft CRM publishing customer address changes to multiple line-of-business systems on the IBM i.
The company in this example uses a CRM system to provide a consolidated view and central entry point for customer information. The information is distributed and stored across several IBM i applications that support various business functions. Updating the customer address in the central CRM makes sense. The problem is how to publish the new address to each of the applications.
One approach is to create an address management function with LANSA to validate address information and update the systems where the addresses are used. The Web services are built as .NET components. LANSA Open for .NET will provide the interface to the address management function for the Web services and hide the complexity of address validation and address distribution from the .NET developer.
Scenario #4 Microsoft Excel spreadsheet retrieving data from an IBM i-based financial system.
Suppose the accountants of a financial management group want to analyze the debtors' ledger, residing on the IBM i. The accountants prefer Microsoft Excel as their working environment and need to be able to retrieve the debtors' data.
One approach is to build a Web service to retrieve the debtors' data and an Excel application that will manage the selection criteria and load the data into a worksheet. The Web service will be a .NET application that accepts query parameters, interacts with LANSA Open for .NET to access the debtors' data and returns a set of data to the Excel application.
The work for the .NET programmer is to build the Web service and the Excel application. LANSA Open for .NET hides the source of the data from the .NET developer.
How does LANSA Open for .NET help manage your architecture challenges?
LANSA Open for .NET insulates the .NET developer from having to understand the IBM i. The developer builds the .NET application in Visual Studio and sees the data and processes from the IBM i server as resources in the .NET environment.
LANSA Open for .NET hides the gap between the .NET and IBM i platforms.