Microsoft SharePoint has grown exponentially since its release in 2003. Did you know it took SharePoint only five years to surpass the $1 billion mark in annual sales? I believe SharePoint was gobbled up quickly by so many companies because it’s relatively inexpensive and easy to build a business case with a compelling return on investment.
That said, I find it odd that in the SMB market – a market that cherishes return on investment (and thus our love affair with the IBM i) – we find little mention of IBM i organizations embracing SharePoint. Microsoft has hit a proverbial homerun with SharePoint, yet it appears few of us on IBM i take advantage of it. If the Magic 8-Ball says SharePoint and IBM i can coexist, then what gives?
I think we need to allow the IBM i community to ask the Magic 8-Ball a few more follow-up questions to bring more clarity to this topic.
Doug – IBM i System Administrator – says, “Our .NET developers want to access my DB2 data from SharePoint via ODBC, but I’ve heard ODBC is not very secure. Is there better way?”
Magic 8-Ball says, “Without a doubt.” Doug, it’s true. There are security concerns with ODBC. Instead, use middleware that provides a secure and native connection with record-level access to DB2. Better yet, use middleware that also compresses and encrypts the data sent across the wire between SharePoint and the IBM i, securing your sensitive data even further. Plus, ODBC can only access data. There will be times when your SharePoint apps need to access information that is not stored in DB2, which brings us to our next question.
Sally – RPG Developer – says, “Our .NET developers can only access data on the IBM i, nothing else. Some of the information they need isn’t stored in DB2. Will their SharePoint apps be successful?”
Sally, the Magic 8-Ball says, “Outlook not so good.” There is a lot of business critical information out there – data that affects how business operations flow and database transactions are processed – that’s not stored in DB2. For mixed Microsoft/IBM environments to be successful, SharePoint must have real-time access to native IBM i objects (APIs, data areas, data queues, OS commands, etc.). Less native access means more duplication, more syncing, more rewriting, more maintenance, more resources and more money.
Let’s look at how LANSA’s low-code platform can help your organization save its financial resources in this article about IBM money.
Jerry – IBM i IT Manager – says, “I just talked to someone that’s planning on running their refaced 5250 apps inside of SharePoint. Is this a good idea?”
The Magic 8-Ball says, ”Reply hazy, try again.” Jerry, the answer to this question depends on how the person plans on using their refaced screens inside of SharePoint. If the person simply runs a refaced 5250 application inside of SharePoint “as is,” then it’s an awful idea because users still have to navigate through the same eight legacy screens as before to view information. If the person programmatically navigates through the first seven screens for the user and only displays the eighth and final screen to the user, then it’s a great idea!
Joanne – IBM i Business Analyst – says, “We have a lot of business logic trapped inside large RPG programs. We don’t have the time (or patience) to extract core functionality into APIs. Is there a way to access this code from SharePoint?”
Joanne, the Magic 8-Ball says, “As I see it, yes.” Similar to the answer above, there are third-party solutions that enable .NET developers to execute interactive 5250 programs in a “batch mode.” This allows them to navigate directly to the specific screen that contains the calculated data you’re after, grab that piece of information and bring it back to .NET. In effect, you can now “service enable” any part of your existing 5250 portfolio to be consumed by SharePoint/.NET – with no changes to the 5250 application’s source code.
Frank – VP of Sales – says, “Creating orders in our legacy systems takes 20-30 screens and the users hate it. Team SharePoint wants to rewrite it in .NET, but Team IBM i says they’re in way over their heads. Is improving this process a lost cause?”
Magic 8-Ball says, “My sources say no.” Frank, Paul Conte touches on this topic in Books 1 and 2 of his eBook Trilogy on Modernization. According to Paul, let your SharePoint team create the new screen containing all the order information, but use “virtual users” to process the orders on the IBM i. Virtual users are batch programs that execute the legacy order screens sequentially, merging in the order data from SharePoint along the way to complete the transaction. This is the best of both worlds – delivering a brand new interface while still reusing legacy code.
My goal for this blog was to make everyone aware that SharePoint and the IBM i can work together in tandem. This isn’t science fiction, its reality. Plus, the Magic 8-Ball said so – so it has to be true! With the techniques described above, IBM i organizations can deliver SharePoint solutions where users can pull-up a single composite screen that contains:
- DB2 customer data
- Order information from a refaced 5250 screen (buried deep inside their ERP, with all the navigation stripped away)
- Dashboard graphs and gauges displaying key performance indicators with data derived from IBM i APIs
- Brand new web parts written in .NET that are fully integrated with native IBM i objects or can leverage an entire legacy process that would normally take 25 green screens.
I’m curious what role, if any, SharePoint will have in the future of the IBM i. I realize that some of us on the IBM i platform tend to shy away from Microsoft products. Ok, “shy away” may have been sugar coated. How about “avoid it like the plague?” I also realize that some of us on this platform don’t like to admit or talk about our use of Microsoft products. But, that said, something compelled you to read this blog – so I ask a favor of you. Please provide feedback on any of the following questions:
- If you have SharePoint, what kinds of applications are you building?
- If you have SharePoint, does it integrate with the IBM i or run on an island?
- If your SharePoint applications are integrated with IBM i, in which way(s) are they integrated?
- If your SharePoint applications are not integrated with the IBM i, what issues are you having?
- If you’re not using SharePoint, what’s stopping you?
Looking forward to your feedback.
