1

After reading about the CEN/XFS programming reference I thought it would be "easy" to write ATM software that will be supported in all ATMs. At first view, the whole standard seems reasonable to me in terms of portability.

However, to my great surprise, I have had access to some ATMs from well known vendors that do not have even the Microsoft XFS manager (msxfs.dll, etc.) installed. I thought this would be a very rare case.

I have been told that some vendors have their own XFS manager. Is it true? I thought JXFS or a vendor specific layer would depend on the CEN/XFS manager under the hood.

If so, do I have to be aware of all vendor dependant APIs? I refuse to believe this industry works like this.

zapador
  • 897
  • 2
  • 11
  • 20

1 Answers1

1

Sad truth is that generig software doesn't work that well on any of the ATMs out there. Generally speaking I belive every vendor creates their own XFS manager. The used XFS manager is pretty generic though so who ever the XFS manager provider is is not that a big deal. Actual device and service provider implementations are the real differences.

So you could write your software to a common subset of the features and you could even get a decent level of operability using that aproach. Well until you need to start and handle the error cases that is. The limitations would at this point create situations that just make that generic software useless in practice.

Reason to that is simply because all the devices are so different on implementation level and thus can do different things during and after error conditions. So even though the CEN/XFS error codes might be the same for two vendors the required operations can be quite a bit different as their responses may indicate different severity or the error condition might be even self clearing on one, but may require operator intervention on an other one.

Because you naturally want all the available benefits from the hardware you have so at that point we start to need configuration options that are just outside the scope of CEN/XFS. After you go that way you start to get the benefits of the hardware, but that also means higher complexity to your software. Oh and you'll need lots and lots of testing as sadly you can't really trust vendor documentation either...

VoltagE-ThE
  • 91
  • 5
  • Thanks for the answer, that this mean that a native app linking MSXFS.DLL is prone to fail... and that I need a copy of every vendor SDK out there? How I can get this? – zapador Aug 10 '18 at 08:41
  • You want to dynamically link for MSXFS.dll, but you do NOT ship it with your application as every ATM with the vendor software installed will have the DLL as that part is strictly standard stuff. SDK is the hard part you pretty much have to ask from the vendor and at least NCR has quite strict policies for their SDK. – VoltagE-ThE Aug 12 '18 at 10:32
  • 1
    @VoltagE-ThE I just want to make it clear to me as i started recently in building my integration to XFS Manager. Each vendor will install his own `msxfs.dll` but all dlls will have same signature as it is standard, and I can get the the XFS manager `msxfs.dll` only from the vendor I cannot installed it from an online site. – Ebraheem Apr 01 '20 at 13:56