Logistics Bidafarma

Medication loading and distribution control app

The client

BIDAFARMA, S.C.A. It is the second national pharmaceutical distribution cooperative by billing volume. With a presence in almost the entire Spanish territory, it is currently expanding.

The challenge

The existing solution was based on Microsoft’s technology stack from 2006. While the backend could still perform its function with low risk and taking advantage of the existing integration with SAP, the frontend, implemented as a .Net Compact Framework 2.0 application for Windows Mobile on Zebra ruggedized terminals had reached their end of life. The migration should be done as soon as possible and with the least possible impact on the service, since the distribution of medicines is a critical task and the risks caused by failures in logistics can have very serious consequences.

The strategy

The client wanted to preserve 100% of the functionality of the app and the existing implementation that, although maintained by LinkedBytes, was inherited from another provider. The behavior of the application had to be replicated and all the logic implemented using existing SOAP services. The UI had to be as similar as possible to that of Windows Mobile to minimize the learning curve for users.

The proposal

The .Net Compact Framework application would guide and prevent changes to SOAP services. The existing application and the new one could co-exist for the necessary time until the fleet of obsolete terminals is extinguished. It is a solution based on barcode readings, so the new solution had to allow readings with the same performance as the terminals in use (Zebra MC75, MC75A and MC67), but without being closed to a specific hardware .

3 alternatives were proposed:

Platform independent app (iOS & Android) with Bluetooth code reader: thus allowing the use of any mobile device with Bluetooth connectivity that received codes from an external reader (such as Zebra’s RS series rings).
Platform independent app (iOS & Android) with OCR code reader: using the device’s camera and the power of the Scandit SDK.
Platform dependent app (Android) with embedded code reader: using the scanner of a ruggedized terminal such as the Zebra TC series. The platform dependency would only be linked to the need to implement access to the scanner through the manufacturer’s SDK.

So that Bidafarma could assess the advantages and disadvantages of each alternative, a pilot was implemented that allowed choosing between the 3 options. After the relevant tests, the client opted for the third option. So we drew up the plan and got to work. Both the pilot and the final app were carried out with Titanium SDK.

The process

What did we do to achieve it?

1 - Initial Analysis

The main problem was that we were starting from a legacy solution and although we had maintained it for a few years, there were some “black boxes” and parts that had never been touched. Communications needed to be analyzed to determine how responses to each SOAP request to the service should be interpreted. One of the requirements was to preserve, as much as possible, the existing UI. This was quite a challenge, as many of the Windows Mobile controls were unmatched on Android, so we decided to approach the project in 2 phases: first to replicate the functionality and second to replicate the UI.

2 - App Phase I

We were analyzing each functionality of the existing app along with the SOAP requests associated with them. With the help of SoapUI we were able to design the service layer that was being used (and avoid deprecated commands). The next step was to persist the entities locally, converting each entity from its XML representation to JSON for easy storage as an Alloy model. While we were implementing both layers (remote services and persistence) we had a mock implementation that allowed us to advance in parallel with the basic UI that would have to be adapted later.

3 - App Phase II

Almost all of the options were implemented during phase I, only with mock services. In phase II we started by replacing the mock services with their actual implementation, and then adapted the UI to be as close to the old app as possible. Once phase II was completed, we began with the validation of the app, for which we had the help of the Bidafarma team, both in the technical part and from the users themselves, who helped to identify and solve the problems that arose.

4 - Deployment

All development was carried out without the need to modify the backend. This implied that the new app could coexist 100% with the old one and the migration could be done at the pace that Bidafarma considered necessary. As a final milestone, a technology transfer was carried out through training and hands-on-lab sessions, so that the Bidafarma development team could give continuity to the developed solution.

Results

Achievements achieved.

100%

MIGRATION

All the terminals were extinguished until reaching 100% deployment of the new solution. The risks of the old solution disappeared.

100%

SUPPORTED BACKENDS

During the migration, the backend did not need adaptations. It successfully responded to requests received from Windows Mobile and from Android.

100%

CUSTOMER SATISFACTION

The project was executed on time and within budget. Users did not perceive a worsening in the use of the app. It is still your work tool.

Customer opinion

Our distribution system is critical, our goods are medicines and we make several deliveries to pharmacies a day. Failure to distribute implies that patients may be left without their medication. We needed a mobility application with quality according to our needs. LinkedBytes took the reins of the solution developed by another provider, allowing the start-up and amortization of the project, complying with our quality requirements. The migration was carried out successfully and without service interruptions.