Building a Modern Line-Of-Business Application: Part 6 - Version Defense Strategy
Modern Line-of-Business applications are no longer self-contained. Instead they are lots of small applications that connect together to make a seamless whole. This increases the importance of keeping client applications on the same version.
As developers and administrators, we want to make sure that everyone is using the newest-latest-greatest version, but that can turn into an installation — and time management — nightmare. Often our solution is to try to do as much on the server as we can because that is centralized. Personally, I find this the best solution, but it isn't always an option.
Since we want to guarantee that the client software and the server software are using the same version, we need to create a version defense strategy. There are 2 basic scenarios that I'm trying to address:
- Handling changes that break compatibility between client and server software
- Handling changes that provide backward compatibility between client and server
Compatibility
Developers will often overlook handling compatibility until too late in the development cycle. Having to retrofit compatibility management into applications becomes burdensome. It is not as simple as just adding it to the server side of the LOB application. It does require the client to be retrofitted as well.
When building compatibility handling, you are going to be introducing a dreaded level of bureaucracy to your developers and IT department. This is more like introducing paperwork than it is like producing new technology.
Don't get me wrong, some new technology is likely to be added just to decrease the administration headaches that you will be introducing. Honestly, more than likely you already have these headaches. They are harder to avoid now.
Managing Version
The first thing you will need to address is how and where you are to manage the compatibility and version information. My recommendation is to keep it on the LOB server, and just have the client verify and respond to the server.
There are 2 different pieces of information that we need to keep track of:
- Overall LOB version and compatibility
- Client session version and compatibility
Client Session Version and Compatibility
I would recommend keeping a record of all the clients that are connected — or have been connected — to the LOB server(s). This will provide administrators the ability to plan upgrades when any are needed.
<Connection API Name or App Name>*<Client or Location Name> Ie: JAVA*10.0.0.2 DOTNET*WORKSTATION1 DOTNET*DOMAIN\NATHAN@WORKSTATION1 EXCELADDIN*WORKSTATION1 OUTLOOKADDIN*WORKSTATION1 <1> = Version Number (ie: 1.2.3.aaa) <2> = Platform (Windows 7, Windows 10, iOS, Web) <3> = Date Updated <4> = Time Updated <5> = UserName Update
As I talked about in my last article, the Connection API defines an easy way for a client application to access the LOB APIs. There can be more than one type of Connection API that interface with the same Business API.
Since it's typically the Connection API that is in need of upgrades, we need to know what APIs are being used where. There are times when a Connection API just isn't enough, so an application name can be used as well.
An example of this: you've built a specific windows application which interfaces with your LOB APIs. Even if this windows UI uses another client (such as .Net or Java) there should be a listing here for that application as well. This allows you to see who is using which applications, as well as who is using which Connection APIs.
The "client or location name" is mainly the computer, device, or location identifier. For anything in your network, you want the name of the computer at least. If this is an off-site application you may want the IP address or some other identifier for that remote location. If used on a mobile device, then I would recommend using the name of the device so administrations have a means of tracking it down.
Personally, I have found when using a windows machine, having the workstation name and the currently logged in windows user name is helpful. If your IT staff is not in control of where software gets loaded, then sometimes it can get loaded into a user's roaming profile instead of on a specific machine. Knowing the Windows username, in addition to the workstation name, would help you isolate this sort of hiccup.
Again, this is important information. It helps your administrators plan bulk upgrades. It gives them insight into when it may be necessary to force users of a specific version to upgrade.
Overall LOB Version and Compatibility
Version and compatibility settings come in different forms. I'm not talking specifically about source code version control, or workflow version control, but generalized client/server matching. Source code and workflow version controls are part of this process, but is designed to handle a different requirement.
When you separate applications into multiple parts — split between different client applications and the server — you have to keep those parts in sync. This means you have to keep track of API versions, either for backward compatibility or just to notify client applications when it will no longer work.
I have chosen to use a complex key to help represent different bits of information.
<Connection API Name or App Name>*<Version Number> <1> = Build Id (used as a reference point back to Source or Workflow controls) <2> = Build Date <3> = Build Time <4,n>= Build Notes <5> = Upgrade Version Number <6,n>= Upgrade Message
As I talked about in the Client Session Version and Compatibility section, the Connection API or App name is important. Remember that it is possible that you can have different versions of Connection APIs due to bug fixes or enhancements.
Each record will represent a separate version number of the LOB application. This allows you to include build dates, IDs, and notes that can be used for reference or explication. It also allows you to define upgrade requirements for each specific version of the Connection API currently being used.
The Upgrade Version Number field is used to define which version number should be used when an upgrade is done. The Upgrade Message is used to provide a human readable message about the upgrade.
Once you have all this, you will need to provide a means to check to make sure the client can check its version.
Version Checking API
The API used for version checking should be an independent Business API so it can be done at anytime throughout the application workflow. Ideally, you would do this check at logon, before the application has done any loading of the Business API data or applications, but things are often not ideal.
API:
VERSION.CHECK
Request:
- VERSION.NO = Version number the Client/Connection API wants to use.
- CONNECT.API = connection API Name or App Name
- CLIENT.NAME = Computer Name and/or Computer Login.
Response:
- STATUS = Ok, Upgrade requested, Force Upgrade
- UPGRADE.MESSAGE = message to display about upgrade needed/required
- UPGRADE.VERSION = version needed to upgrade to
- LOB.API.VERSION = Version of LOB API that is going to be used
It is import to note that I'm returning the LOB APIs version as well. This version is likely within the same as the Connection API version, but as bug fixes and enhancement in the LOB API are made, it is important for the client to know if there is a difference for some reason.
VERSION.CHECK Status: Force Upgrade
This is the easier upgrade process to code. The basics being that everything stops and the application will terminate with a message that an upgrade is required.
The more advanced approach is to do the upgrade automatically, but that may not always be feasible depending on the application, security settings, or other issues.
VERSION.CHECK Status: Upgrade requested
This status notifies the application that the LOBAPI has a different version available than the client is actually using, and that it is recommended that the client upgrade to the new version, but is not required.
This allows the user to be aware of enhancements, but not force them to upgrade until they are ready to do so.
If you want to be able to handle this type of version strategy, then you will need to include the client/connection API version with every call to the Business APIs as well. This way the Business API can make decisions on how to handle different version of the requests.
Version Information API
Information on the current version is important information to the administrator and tech support. I would recommend also including an API that provides information about the current version the client or Connection API is using.
API:
VERSION.INFO
Request:
- VERSION.NO = Version number the Client/Connection API wants to use.
- CONNECT.API = connection API Name or App Name
- CLIENT.NAME = Computer Name and/or Computer Login.
Response:
- BUILD.DATE = Date the version was built on
- BUILD.TIME = time the version was built on
- BUILD.NOTES = the information found in the build notes.
- UPGRADE.VERSION = version next that this API can be upgrade to.
Conclusions
Version checking can get very complex. It will vary depending on how you want to write your applications, but it is important to plan it out ahead of time. This is how your Modern Line-of-Business Application needs to handle code changes across disconnected applications and multiple devices per user.
