rfsmart or DSI

Shahid Equbal

Member
Folks,

A curious question and probably very basic.
I have been trying to have a subjective comparison of DSI from dcLINK and rfsmart. While the information about the individual products abound the internet, the specific comparison information is rather sparse.
Probably because there is not a lot of difference between the two and they both accomplish similar things.
I have been exposed to DSI and am familiar with its capabilities, more so when JDE software offers Business Function wrappers to leverage the MBFs in JDE.
My new project has rfsmart and I am trying to get some exposure there as well eventually. In the mean time I was trying to find out in what ways are the two different, if at all.

This is not from a decision making perspective, but lets say if I ever have to make a decision (irrespective of cost) between the two, what factors should I consider.
For the sake of discussion if it helps, lets assume that the base JDE software is 9.1.

Appreciate any information on this topic

Thanks and Regards
Shahid Equbal
 
Ever since the beginning of OneWorld, the barcoding providers have tried to create a simple method for connecting their product to E1. Over the past 20 years, there have been some disasters in some of their releases, and a lot of success in others. However, I believe that all the products today are so similar, in both scope and implementation cost, that its very difficult to identify a single product that is "better" than another between the three. Certainly if a customer were to be looking, they should be looking at their functional requirements versus the barcode providers built-in functionality. That single decision will likely identify one vendors' product over another.

Ease of implementation was always the difference between the solutions - and these days, each of them can be installed pretty easily.

However, ease of modification is often overlooked - and I think this is where all three vendors fall somewhat. Currently, each of the vendors use either direct database connectivity, or Business Function connectivity (through CallObject) - and this means that if a customer modifies the applications, they might have to modify how to connect to the barcode solution.

Ultimately, the best way to get around this is going to be through the AIS solution that JDE provides. Unfortunately, non of the Barcode vendors support integration through AIS currently - but thats understandable due to how new AIS is. But I really, really believe that AIS is the future of JDE - and that all integrations should be evaluating the use of AIS - including barcode solutions. Whichever of the three vendors change their integration methodology to AIS will likely "beat out" the other two vendors in ease of implementation AND ease of modification.

Thats my 2c. We'll have to see if either of the three vendors change their integration methodology.
 
Ultimately, the best way to get around this is going to be through the AIS solution that JDE provides. Unfortunately, non of the Barcode vendors support integration through AIS currently - but thats understandable due to how new AIS is. But I really, really believe that AIS is the future of JDE - and that all integrations should be evaluating the use of AIS - including barcode solutions. Whichever of the three vendors change their integration methodology to AIS will likely "beat out" the other two vendors in ease of implementation AND ease of modification.

Thats my 2c. We'll have to see if either of the three vendors change their integration methodology.

AIS is one way to integrate with JDE but it is not the only way to integrate with JDE and there are some limitations and issues to consider. Performance is going to lag behind other methods due to it effectively being a screen scraper against a JAS server. Also, your comment about modifications needs to be put into context. If you create an integration with AIS to one or more applications and then modify one or more of those application's forms then your AIS calls have to be updated to suit. Also, if you start with modified apps then in most instances you will have to modify or re-create any pre-built AIS integrations that use those apps. Another point is that without the IoT Orchestrator (which is separately licensed), integrations on the calling side can be a pain to build in more complicated situations.

Lastly, AIS integrations tend to be very specific to a particular requirement and aren't going to be reused. If you have a requirement for a rest service to create new customers. You're unlikely to define a service that is also compatible with creating a supplier or employee as well because the orchestration for that would be significantly more complex. However, if you use BSFNs to do the same thing then this is much easier to achieve.

On another note, please don't lump all of the mobile/barcoding solution providers into the same bucket. While DSI, RF Smart and RF Gen may be a bit set in their ways there are more than just three options in this space and some of us do things a bit different and a hell of a lot cheaper as well. Our next point release will include the option of using AIS as an alternative for those customers that are on the latest tools release but it just one of the options and for customers still sitting back on earlier apps and tools releases there are still effective options.
 
I agree AIS is a presentation layer integration point, and aimed at leveraging existing apps for mobile platforms ... which is a huge marketing angle. IMHO, XML call object provides the cleanest interop solution when it comes to customer examples. Subject to change, just sayin.

Craig
 
I have worked with both and found they are equally excellent and pose no major issue in any way. I also found that for me it came down to the best deal that can be negotiated. In short both are excellent and have long successful track records with JDE customers. Good luck with your negotiations.
 
However, ease of modification is often overlooked - and I think this is where all three vendors fall somewhat. Currently, each of the vendors use either direct database connectivity, or Business Function connectivity (through CallObject) - and this means that if a customer modifies the applications, they might have to modify how to connect to the barcode solution.

Good point. We use rfSmart which calls their own BSFNs via XML CallObject which in turn usually call Pristine BSFNs. This architecture has allowed us to make modifications at the MBF level for most things and as a result mods are generally not needed by any of the rfSmart code. We do have some some rfSmart specific mods but most of the time if we need custom processing to happen during some business process (the PO receipt process for example), we simply modify the PO receipt MBF and then the mods work if the receipt is done via rfSmart or native JDE applications.
 
Back
Top