Infor's SXAPI Problem and Solution

For those of you who are not technically inclined computer-geek types, you might want to pass this post up. However, if you happened to stumble upon it while looking for a solution to a similar problem with Infor's SXAPI, please read on and I hope it helps.

The company I work for has a dozen or so regional offices. As a service to our customers, we have a secure proxy to our Regional Sales System so they can check stock at their convenience without having to call and wait for a sales rep to get to them. It's a good system for our customers and for us.

We are in the process of changing to Infor's system for our regional offices. We, of course, want to offer the same stock-checking service to our customers via our Business-to-Business (B2B) web site. Infor has an API to facilitate writing ASP.NET web applications which will allow us to do just that. They call it SXAPI.

In our development environment, the SXAPI worked like a charm. We could hook into the sales system and query stock levels to our hearts' content. We were really jazzed about being able to give our customers an easy to use and powerful system to help them do business with us better and easier.

That was, until we tried to set the SXAPI on our production server for testing. We have our B2B in a DMZ between firewalls going out to the WWW and in to our network. I arranged with our network admin to make the proper adjustments to the firewall and I thought we were all set. Boy was I wrong.

When it came time to install the SXAPI it took forever. First off, in order for it to install itself there must be a web site in IIS called "Default Web Site." If there is no such web site, the install will bomb. Of course, on a public-facing web site, we don't keep anything "default." It took the tech support guy at Infor a little while to figure this out.

Once we got the SXAPI installed and configured I ran their "Canary Test" program to check the connection to our back end Infor server. The Canary Test is a cute little app with a picture of a canary on a perch. When you do the test, if it succeeds the canary stays on its perch and you get the "success" message. If the connection doesn't succeed, the canary "dies" and the picture changes to a canary on its side with an "x" over its eyes. Unfortunately, the canary kept "dying."

For two weeks I went back and forth with my Infor tech support contact. He had no ideas why it wouldn't work. I sent him error messages, reports from the Infor server confirming I was trying to connect to the correct IP Addresses and ports, and other information. In between emails and phone calls I worked with two of our network admins checking for messages in the firewall logs and running sniffer traces to see if we could diagnose the problem. I even went and gave my Infor tech contact all the details of our network configuration so he could replicate it and try to diagnose the problem.

The production B2B server has 2 NICs; one goes out to the WWW and the other only connects to a SQL Server we run for dynamic content - both are on different IP subnets. Even though we have static routes in the B2B server to send the traffic in the right direction, for some reason the packets the SXAPI generated were trying to go through the NIC for the SQL server, which is in a non-routable address segment. No matter how we tweaked the static routes or messed around with the settings on the server, we couldn't get the traffic to go out the correct NIC to our Infor server. Our tech contact at Infor didn't seem to understand the problem, and finally told us he was punting to a developer to see if any light could be shed on the problem. He even told us at one point that the canary test probably wouldn't work through a firewall since it did more than just test for a good connection.

In the meantime, I've got a lot of people who want to have this API working (most of all me, 'cause I've got a lot of other things to do) so our customers can take advantage of the ASP.NET inventory query app we wrote. Nothing seemed to work at all. There was no documentation on this kind of issue, no solution coming from Infor tech support, no Usenet or other tech groups, nothing. It was very frustrating.

While I was talking out the problem with one of the network admins, he suggested I disable the NIC the SXAPI was sending its traffic through to see if it would be "smart" enough to route the traffic through the other NIC. I was ready to try this, but thought there might be another solution.

This morning while I was getting ready for work, mulling over this issue, something hit me. When putting IP Addresses in a Windows server, when you route traffic out and don't specify which IP Address it should go through, Windows defaults to the first IP Address you entered. I started to think, what if the SXAPI was looking at the registry and routing its traffic through the first NIC installed instead of the one the Windows routing table was telling it to go through. Instead of letting Windows handle the network and routing, I wondered if it was handling the routing itself. I happened to remember the NIC handling the SQL Server traffic was built in and the one handling the WWW traffic was a PCI card I installed. The NIC with the SQL was installed first.

To that end, I swapped IP Addresses in the 2 NICs installed on the server and swapped the cables so they'd go through the correct routers - and behold - the canary didn't die when I did the test.

So, if you happen to stumble on this looking for answers to routing issues with Infor's SXAPI and you have 2 NICs, take a look at the order the NICs were installed.