If you followed Peter’s series on replacing Lotus he outlined some of the pitfalls, processes and decision points to undertake for success. I wanted to point out the technical side to a lot of those decisions. The short answer is that you need a tool to surface your domino data en-masse until such a time when decisions are made on each application. I have been working on that solution for quite some time now and I have to say, it’s complex.
First you need to make a fundamental decision. Are you going to do this yourself or hire someone? Next question…Are you going to provide fidelity to the original Notes apps or not? If so, your life just got much more difficult, stressful and confusing (and/or expensive). Also, what logic can be saved from each application if any? Making that determination in itself can be complicated because you need a way to tell if code is being used or not. How common is the code? Is it being used all over the place or just in one application? Can it be ported to Java? If it’s already in Java you’re a step ahead. So, you need some type of forensics tool.
Once you have a REST service and a place to store rendering information and a tool to produce, configure and maintain that rendering information you can start writing the code to render data from domino. This probably will need the consultation of a good Designer. Let’s face it, we’re good at writing code, but not very good at producing UIs which are intuitive, functional, maintainable and pretty. A Designer will help you immensely with this piece. The upside here is that you can develop pieces of this app that will be reused everywhere, because pretty much all domino apps have the same characteristics (i.e. Views, Forms and Documents). So you develop a “View” component, “Document” component and you modify the form with the tool you produced to maintain rendering information.
Now that we’re able to start rendering data from our domino apps, you need to answer some very fundamental questions about which views you’re gonna surface and what exactly are you going to allow users to do. Oh yeah, and you’ll need a tool so that someone can maintain this configuration. But other decisions to be made: Will they have permission to edit documents? If so, what about workflow? Since you’re now moving from the realm of Notes/Domino and into the Web Realm, what are you going to do about the fields presented for editing that data? Do you want/need name pickers, value pickers, multi-value fields, date pickers, time pickers, etc.? All of these affect the complexity. If you’re not going to enable editing, your life just got somewhat simpler, but not a whole lot. But let’s assume you decided to enable editing (you’re gonna need a bigger can for those worms).
With the decision that you will allow editing of documents, now you need another tool for configuring fields. This field configuration tool needs to allow you to see and change field types (i.e. Text, Number, Telephone, Url, Email, Name, etc.), since now we’re on the web it’s important. This alone is complex enough because in a Domino app you can put a string in a date field, you can put a date in a text field, you can have empty values and all kinds of nonsense. Field typing in Notes was not enforced. So, a lot of thought needs to go into how your fields are rendered and if there are any fields which are linked or dependent on another field (i.e. comboboxes whose keywords change based on the value of other fields). So your field configuration tool needs to be aware of a lot of different things and be able to maintain that rendering information.
Once you can configure the fields found on a form/document we’re now ready to start creating or stealing and modifying all the different pickers we’re gonna need. We also need to take into consideration field value validation. Also, do we save changed documents every time you edit a field or when a save or submit button is clicked? There are several valid arguments to either paradigm. Once we have all of our field types in place, we need to be able to logically determine what type of field we render for each item on a document. This alone is complex and you need to be extremely mindful of performance here because following the path of least resistance will probably mean you have a butt ton of code to run and performance can suffer tremendously. I’ve only mentioned some of the hurdles you’ll need to overcome to render a document, but as you can see, it’s complex and we haven’t even thought about workflow yet or rich text (I’m gonna skip rich text all together, it’s complex).
So, what about workflow, what choices do we have? Well, there are a couple: 1) We can move ALL of the code found in our original app into agents that can be run from the web and execute workflow that way. We just need to take into account document changes and UI operations. 2) We can port this code to Java and make it possible to tie into our REST service, which is probably the easiest solution here. Why would I say that? Because it is the easiest solution. When we move all that existing code into agents, now we have a lot of references that will need to be hard coded in order to call those agents. Hard coding things makes it almost impossible to make it dynamic in the future, so by doing the porting to Java now, you’re actually saving yourself time in the future. Not to mention you’re moving your code to a language that has a future and can move to another platform for the most part.
I’ve left a lot out a lot of the decisions you need to make if you’re going to replace Lotus with something else. Peter’s series covers these in quite some detail, but I wanted to point out the technical complexities of the task. I also wanted to re-iterate that there is no magic button, nor will there ever be one. The problems are too complex to solve easily. We can create tools that address 80% of your application portfolio, but the other 20% is complex.
Until next time…. Happy Coding