Behind the Scenes with Lanham’s E-Ship NAV Extension Developer
Posted on March 2, 2017Lanham has been on the leading edge in terms of innovative supply chain software development since its beginnings almost two decades ago. More recently it has been aggressively developing many of its products as NAV Extensions, which will enable customers to extend Microsoft® DynamicsTM NAV functionality without modifying base NAV.
To date, we’ve rolled out a number of our products as NAV Extensions and are busy extension-izing even more of our supply chain planning and execution solutions.
In this Q&A, Bill Sanders, Lanham E-Ship Product Development Manager, sheds some light on the difference between traditional software development and extension development, what the E-Ship extension does and doesn’t offer, and how it can further enhance customers shipping processes.
Q. What were your objectives for developing the E-Ship NAV Extension?
We set out to deliver E-Ship and all of its core functionality as an extension. We wanted it to include E-Ship, E-Receive, E-Mail, and all of the supporting carriers that are offered with the more traditional E-Ship product.
We also wanted to offer a product that looked and behaved like the E-Ship product with which we are all familiar. It would have been really easy to change screens and pages and make it look a lot different, but we didn’t want to have a product that looked drastically different from the original. And we wanted to be able to offer the same or a similar degree of integration with the base NAV application. This was the part that we thought might be most challenging, because one of the biggest advantages of E-Ship is that it is fully integrated with the ERP system, and we wanted to have a similar degree of integration for the extension.
Another objective was to offer the initial E-Ship extension product separate from Lanham EDI. When you install the standard E-Ship product, you install all of the Lanham EDI functionality as well. With E-Ship as an Extension, we wanted it to be offered independently. This presented quite a challenge since the code bases were so intertwined.
Q. Did you meet all of these objectives?
Fast forward to the end of the development process, and we did end up with a full-featured product that is integrated to the same degree, with no reduction in functionality or usability. The product looks and behaves in an almost identical manner to the standard E-Ship product. I say almost simply because we made minor changes in some of the set-up forms, but this has not impacted any of the functionality or its usability.
Q. What were the most striking differences between more traditional software development vs. extensions software development?
It’s a whole different way of thinking/developing – We’re not in Kansas anymore, if you know what I mean! There are some inherent limitations placed on extensions development which required new levels of perseverance and creativity. Rather than having free-reign to modify any object in the system in any way that you want, you are forced to find ways of accomplishing the same thing with minimal or, in some cases, no impact to the base NAV system. Nonetheless, I’m happy to say that we’ve come out the other end with a great product.
The delivery system is different – Another big difference is in how we deliver the system. Once we finish the development process, we have to create an extension package. To do this, we take all of the code that we created for the extension and compile it into a binary format. It’s not source code like we are used to having in the NAV product. It’s not open or available for any kind of modification. This binary package is then installed on top of the base application. What the end user receives is the functionality, but it’s not possible for any of its source code to be accessed by the customer or the partner either.
Installation method – Installing extensions requires a process very unlike what has been done in the past. Previously we would create the objects and then export them. We’d put them up on our website. Our partners would download them, and either merge those objects in or just import those objects and replace existing objects in the customer’s system.
In the extensions world, it’s not going to be quite that easy. Now it’s going to involve a process where Windows PowerShell is used to install the extension over the base NAV functionality. This has proven to be a bit confusing for those who have grown accustomed to importing objects from within the development system. The good news is we have created a simple-to-use utility, called Lanham Extension Manager, which handles the process of managing your extensions. We’ve also created some easy-to-follow, step-by-step instructions, and will be publishing them in an upcoming blogpost as well. Overall, I think most will find the process can be done rather quickly.
Q. What are the main benefits of NAV extensions?
Speed – The installation is very fast. I have installed the E-Ship Extension on computers here in our test labs in as little as 15 minutes. This includes installing the functionality in the system as well as data setup. Check out the speed metrics at the end of this post. It is a very quick process.
Upgrades are much easier – and they’re handled by the system. You don’t have to worry about code merges and manual application of changes. The old version of the extension is uninstalled, and the new version is installed in its place. The system conveniently archives any existing data so that it can be smoothly upgraded from one version to the next one.
Q. Any other differences between traditional E-Ship and E-Ship Extensions that will affect customers?
With all the benefits of NAV extensions, there are a few disadvantages worth mentioning. Specifically, we’re not going to be able to offer hot fixes in the traditional way. Before, if there was an issue that we had to address, whether it be a change in one of our carriers or we found that we needed to make a change somewhere else in the application, we could go in and just make a change in the object and produce the object. You’d go in and import the object code, or merge the object, and it’s there and available for use. Now, in this extensions world, it’ll be a little more complicated in that you will have to uninstall and reinstall the package with the new hot fix in it. Obviously, from our end, we’ll have to rebuild the entire extension package each time any change is published.
Q. What types of customers are a good fit for E-Ship as an extension versus the standard E-Ship product?
Customers that have shipping needs that are handled with base, out-of-the-box, vanilla E-Ship functionality, are prime candidates for this product. Since extension code cannot be accessed or changed, it’s not for customers who need or want lots of modifications. At this point in time, it’s also not for customers who need EDI. If you need EDI, we recommend the more traditional route. But stay tuned, because we are working on developing EDI as an extension too.
Q. If an existing E-Ship customer is interested in upgrading to E-Ship as a NAV Extension, but also would like to have EDI, would you recommend that they wait until EDI is available as an extension before upgrading?
Yes, I would. At this point, E-Ship is only an extension by itself. It’s intended only for customers who need E-Ship functionality without EDI. I would recommend if you have E-Ship and feel you may eventually want to add EDI, that you wait for the EDI Extension. It won’t be as long as you might think. We plan to have some updated information on this during our product roadmap session at the Lanham Supply Chain Summit in April.
To learn more about all of Lanham’s NAV Extensions please subscribe to this blog or email us at education@lanhamassoc.com.
