xAuthorize COM Working NAV 4.00 SP3 not in 5.00 or 5 SP1.

shepardassoc

We have a client that we recently upgraded to 5.00 SP1 and xAuthorize.dll is no longer working. If run a 4.00 SP3 client or eariler all on the same machine is works fine. If you connect to the same database with a 5.00 or 5.00 SP1 client the COM stops working. Automation varible compiles, the COM object gets created, and you can even assign variables in the COM's properties. The COM just wont run the methods. Just wondering if anyone else has had issues with 5.00 clients not responding to COM objects.

tmcguire47

Hi. It is really odd that you posted today because I am having the same problem after upgrading to 5.00 SP1 today. I was using the xauthorize 5.5 version. I tried updating to 6, but that cause NAV to crash...before updating it was just saying the transaction was declined.
any ideas? This will keep us from going to 5.00 until we figure something out.

shepardassoc

I've been trying every which way to figure this out. xAuthorize thinks it's fine because it works using the VB App that comes with it the program and it works using clients other than 5.00. Baffling to say the least. Were looking at creating a VB Wrapper and see if that works otherwise were onto a different authorize software.

wakestar

Try http://www.blunck.se/comtrace/comtrace.html and see if it gives you some useful informations

tmcguire47

What NAV objects do you use that call the xauthorize dll? We use the archerpoint module.

do you know what version of the xauthorize dll you have?

shepardassoc

The Credit Card Management Codeunit. We use Archer as well.

tmcguire47

Hi,
We emailed archerpoint. They said they have known about this and they worked with msoft for 6 months without finding a solution. they say they no longer support the software anyway and we should figure something else out.

we are going to try something like a wrapper and see what we get, will let you know
-tim

jgentle

In dealing with tmcguire47's issue, I spent today making a C# .NET class using the XAuthorize DLL in a manner that would expose the properties/methods used by the Archerpoint NAV Codeunit as a COM server. That part worked fine. NAV sees my new methods and properties just like they did with the original XAuthorize DLL. The problem is that the behavior is virtually identical.

I am able to create a test C# application that makes use of my new class that references the XAuthorize DLL and obtain a successful result all day long, but accessing the same class through COM (from within the NAV process), the behavior is the same (always decline). I did some analysis using the ComTrace tool mentioned by wakestar with the following results:

Running against the original XAuthorize DLL:

Error in WinHTTP.WinHTTPRequest: The process cannot access the file because it is being used by another process.

Running against new C# COM Server:

Error in CoCreateInstanceEx(WinHTTP.WinHTTPRequest): Not enough storage is available to complete this operation.

My thinking is that accessing properties and methods of this DLL is no longer going to work from within the NAV process thread, for whatever reason. My strategy now will be to take advantage of the code I've already written to expose my C# class as a web service, then figure out how to consume that service from NAV. I think that by having the XAuthorize functionality running outside NAV, the problem behavior will disappear.

Obviously, this introduces new considerations with respect to security, which is why it wasn't my first choice of approach.

wakestar

jgentle wrote:

Running against the original XAuthorize DLL:
Error in WinHTTP.WinHTTPRequest: The process cannot access the file because it is being used by another process.

hmmm... In this case I would use "Filemon" from sysinternals to see which file cannot be accessed because of which process

shepardassoc

One solution we have found that works is to write a DLL in .NET that use the Authorize.NET code standards provided by their website. It works by sending commands through the Authorize.NET secure web address. It would request a good amount of code to be written and tested but it works without the use of xAuthorize.

brad77

I've been working with Jack on this issue, and we've resolved it with a different approach. We tried using a C# COM wrapper like you describe, Shepardassoc (see Jack's comment). It worked when used with a WinForms .NET application, but had the same problem when used within Navision.

The solution we settled on was to implement a .NET web service that utilized the xAuthorize COM component to make the request on behalf of Navision. NAV code had to be added to handle the web service, but it now seems to work quite well. Also, because it uses xAuthorize, it will continue work with all of the existing Gateways that xAuthorize is compatible with.

One point of note: This solution will not work in the 64-bit version of IIS with the x64 version of the .NET Framework. The problem is described on the MSDN forums.

Also, keep in mind that some security considerations should be made when using web services like this (like using SSL and authentication) to avoid sending credit card numbers in the clear over your network.

If you think that this approach may work for you and are having trouble, feel free to PM me with questions (or ask them here).

Brad

tmcguire47

Hi,
I just want to confirm that the solution provided by brad and jack is working. We have it rolled out in production and processed 250 credit card orders yesterday. So as the client, we are very happy, and I heartily recommend OfficeOps (my NAV VAR/partner of record/whatever it is called these days, Jack and Brad are some of their rockstars)...I mean, from friday to tuesday they produced this workable solution, while the canned response from the module's original authors was that they had already spent 6 months working on it with msoft and we should try another solution. anyway, not to rip on anybody specifically, but my company is thrilled to be working as we always have, vs having to go deploy icverify or something else entirely new to us.

But thank you very much forum peeps, the fact that shepardassoc
posted on the same day that we had this problem really checked my sanity and helped us out and the comtrace tool is very interesting and useful, so thanks for that wakestar.

i love it when stuff works out.
-tim