TagISV Solution

Converting an ISV solution to an extension: Update 2

I realize it’s been a bit since my last update. I decided to take a week of vacation (no, not brought on by this conversion process!), and then decided to build a separate app to compliment our ISV solution.
Back to the conversion project….I’ve been able to spend a little over a week worth of time since my last update , so I’ve got a few things I want to cover.

Environment

I was asked a little while ago what the environment is that I’m using, so I’ll quickly explain. I’m using a 100% Docker-based system running locally on my Windows 10 Surface Book 2. With the luxury of 16GB RAM available on my machine, I’m able to dedicate 8Gb to the container which allows for a nice smooth experience without having to switch to Windows Server. If you want to get into building your own Docker system, check out Freddy’s post to get started.
As for the image I’m using, I’m using the Business Central insider builds. You may want to choose another image to use, or if you do not have access to the insider builds, refer to this post to determine what’s right for you.

Where I’m at in the Process

At the end of the last post, I had tackled some of the easy things. Now I’ve been able to get through a large chunk of the more tedious things. Remember, I’m not necessarily fixing issues right now, I’m still working my way towards an extension that builds and publishes.

Issue 1 – Report DataItem Naming

One of the issues that came up was with the converted reports. It appears as though that in our original reports, we had named various dataitems with the name ‘Labels‘. Well, guess what is a reserved word in AL? This was an easy fix as it just involved renaming the dataitem. Since then I’ve tried to reproduce the error but can’t so I’m wondering if this has already been fixed in the more recent AL Language extension that I’m now using.

Issue 2 – TextConst Dropped in Conversion

This is a weird one. I’ll mention it here in case anyone else comes across this, but somewhere in the conversion of my CAL objects to AL files, a bunch of TextConst variables were dropped. I don’t know why, and there’s a possibility that it was something I did, but nonetheless, I had a bunch of files I had to go through in order to fix the missing variables.

Issue 3 – Trigger Modifications Unsupported…or are they?

This one was a bit annoying, but I understand why it gets flagged by the Txt2AL conversion tool. If you’re converting an ISV, you’ll be almost certain to run into this.
In our table and page extensions, there a load of places where we had put code in various triggers, such as onValidate, onOpenPage, onAfterGetCurrentRecord, etc. All of these changes were marked as “Unsupported” during the conversion process.
In your extension object, you do get a nice indicator of what the change was. The example below shows that I had made a modification to the onOpenPage trigger and added some code at the end to populate a ‘User ID Filter’. I often found myself going back to C/Side just to confirm the exact modification and what code was around it.
UnsupportedFeatureTrigger
This is a bit misleading though as you can create the necessary trigger in the extension file and then add your existing code to it. Using the example above, my extension file would now look like this:
UnsupportedFeatureTrigger2
The caveat to this, and the reason why the conversion tool flags these changes, is that you have to be conscious of when the triggers are fired and where your original code was within the trigger.
If your original code was at the start of the onOpenPage trigger, your new code that you add to the onOpenPage trigger in the extension object will not fire until AFTER the “original” trigger fires. Given this, while you may be able to recreate the triggers needed and then put your code in them, the code may not actually be firing when you intended.
If your existing trigger code was somewhere in the middle of the old trigger code, you will need to rework your solution to work within the onBefore/onAfter structure.
Some triggers (e.g. onInitPage) are not available in extension objects, so you need to also be aware that. Available triggers also change depending on whether or not you are adding your own field/control to the page, or modifying an existing one.
You can always see what triggers are available to you by pressing Ctrl+Space after the trigger keyword.
triggerLookup
Knowing all of this information, you can see why it doesn’t make sense for the conversion to automatically assume all of your trigger code can simply be moved over ‘as-is’. This one’s going to require some developer know-how!
Alright, I think this is it for now. I have more updates to share, but at the risk of turning this post into a novel, I’ll save those for the next post.
Until next time, happy coding!

Converting an ISV solution to an extension: Update 1

Well, what can I say……….this is going to take a while. 🙂
If you have no idea what I am talking about, start here.
After getting the objects converted to AL (using the standard process documented here), I was immediately greeted in VS Code by just over 8000 errors/warnings. Great start.
Luckily half of those were generated by the code analyzers. If you don’t know what they are, see here. Yes, at this point in the project I am considering that half of my issues are “only non-standard and poorly formatted code”. Gotta try and stay positive!
This brings me to my first “recommendation” in this process:
Turn off ALL the code analyzers.
The code analyzers are enabled by default, but can be turned off in your VS Code settings (see here). Once I get to a point where the “non-syntax” errors have been addressed, I will re-enable the analyzers and then deal with that barrel of fun. I’ve done this before in much smaller apps and very quickly got tired of typing ‘()’ 🙂
After disabling the analyzers my list of errors/warnings was brought “all the way down to” just over 4000. Oh wow I’m halfway done!! Ha ha.
The next thing I decided to tackle was another fairly easy one. Dealing with Product Group Code. If you’re not already aware, the Product Group Code feature was deprecated in favour of an improved parent/child Item Category structure. The Product Group Code fields however, were left in the product (not sure I like that, but we can deal with it) and marked for removal (see ObsoleteState property here). This causes any references to those fields to be flagged as warnings. Your code will still build, but this is a heads up that at some point in the future the fields will (probably!?) be removed. As I’m already head deep in things to fix and rework, I decided I’d rather not wait and I will remove references to those fields now.
For me, removing the references to the Product Group Code was pretty easy. We didn’t have major functionality tied to that field, but other ISV solutions may require more effort to remove those references, or, you may just choose to not deal with that now. Up to you.
That’s my update for now, back to fixing more issues. More updates to come!
Happy coding!

Converting an ISV solution to an extension: The Beginning

I’ve been a bit neglectful of this blog for the past couple of months, but with good reason. I’ve been jumping around multiple projects, and have now landed on a project that will involve taking a roughly 3000 object ISV solution and converting it to an extension.
Easy task? Far from it.
Challenging? Most definitely……but that’s why we do what we do right!?
Will I be able to convert it all to an extension? Not likely. (Yes, extensions still have limitations)
What I want to do is post my journey through this project. It’s not going to be a step by step of what to do as this is the first time I’m doing this. Up to this point, my extension experience was building them from scratch, or taking small pieces of existing features and recreating them as extensions. Nothing on this level yet. In all likelihood, I will make some mistakes, or perhaps do things in a less than ideal way, but that’s what I hope to capture in these posts, so that hopefully others can learn form them……and so I don’t make the same mistakes the next time I might have to do this. 🙂
Now first off, I want to be clear that having a 3000+ object extension is not ideal. It’s not the actual end-goal of this project. The overall solution will eventually be broken down into a set of smaller extensions, but as the current design and code is so tightly integrated, we’re moving it all to AL now and will break it apart later.
My “plan” (I use that word loosely) for this project when I began was to do the following:

  1. Convert all net new ISV objects to AL.
  2. Convert modified base tables and pages to AL (e.g. table/page extension files).
  3. Rework existing C/Side objects to move to an AL-based solution.

The first 2 steps leave me with a large portion of the solution in AL, but also a portion back in C/Side. The objects in C/Side would be the base codeunits, xmlports, reports, etc. that were modified by the ISV solution but can’t be directly converted to AL. That’s where step 3 comes into play. Reworking the objects to use events and/or redesigning the ISV solution is going to be required to clean up those objects. All in all, a lot of work, and I know for a fact that I will come across some design that cannot be replicated in an extension…..so stay tuned for however I’m going to deal with that!
Look for more posts on this as I move through this process. I hope to show both the good and the bad so that people can get a sense of what they’re in for if they come across a similar project.
Happy coding!

© 2019 NAV Bits and Bytes

Theme by Anders NorénUp ↑