The number of calls we have gotten recently from IBM i users that have the need to share functions and data with their .Net counterparts has been surprising. We are seeing strong demand to provide real-time, high-speed integration between the two environments. The use cases range from customers who are building a new UI for their IBM i in .Net to customers that have entire application suites in .Net that need to share data with the IBM i. We are even starting to see companies who are sharing IBM i data and functions with their customers and partners who are using .Net.
We generally start the conversation by asking whether they have looked at the native IBM i tools for .Net connections. The answer is almost always yes but they are looking for something more. Some of the reasons they give for looking for more include:
- They want to create a generic connection layer that will not be specific to .Net but will allow any technology to connect to their IBM i through the same secure and controlled path.
- They want a “loosely coupled” connection that allows them to make changes on either side without breaking the interface.
- They want to be able to call .Net functions and access the SQL Server database directly from their RPG or COBOL code.
- They want to use authentication and single sign on methods like OAuth, Kerberos, SAML, etc. without having to write the code from scratch. Writing these modules from scratch could take hundreds or even thousands of lines of code that must be constantly updated to respond to the latest security threats.
- They want to limit access to only approved IBM i functions and data which requires the maintenance of a large number IBM i user profiles. (They don’t want to provide generic IBM i access).
- They want to be able to automate the generation of the IBM i web services and web service documentation
- They want to be able to orchestrate a workflow that includes calls to several functions.
- They want to easily be able to share data using standard formats like JSON and XML.
- They need comprehensive logging and meaningful error messages to troubleshoot connections.
- They need to be able to monitor and manage the connections. Oftentimes, the IBM i users want to make sure that they maintain control over who can connect to the IBM i.
Some companies tell us that they are concerned about the number of access databases that are being created with duplicate data instead of simply getting the data in real time from the IBM i. Other customers find that their loss of control over connections to their IBM i DB2 database makes maintenance difficult and increases potential security risks.
To help these .Net/IBM i customers, we have wrapped the IBM i native functions with Eradani Connect. Eradani Connect provides a way to securely connect .Net with IBM i data and functions through a loosely coupled, bidirectional interface. Connections created via Eradani Connect support more than 500 different authentication methods so users can choose the approach that works best for their use case. These users can easily generate APIs around their RPG and COBOL code to provide .Net access and they can access .Net right from their RPG and COBOL code. The Eradani Dashboards allow them to monitor and manage the connections in real time. With Eradani Connect we have been able to help these customers create new .Net user interfaces to their applications, integrate their internal applications and provide secure IBM i connections for their customers and partners.
If you are interested in learning more about connecting .Net applications with your IBM i, contact us via our website at https://eradani.com/contact-us/.