Episode 7. Application update

As time goes by, new versions of the application come out. Let’s see what options do we have

when it comes to updating the application.

Any 1C application is an open-source-code one. You can see the entire data structure and all the code just like this.

The modification is a different story, though. These locks and boxes, you can see here, mean that the application is protected from any changes with the exception of official new versions provided by the application vendor.

This is the full number of the current version, and this is the URL where the new versions are to be published. When the news breaks that the next version is available, I just go here, click Update, Search for available updates and this is where the Platform thinks the updates might live at.

This is the default local folder And this is a list you can fill out with all the places you want the Platform to look for updates at. This is the URL that supposed to host the new version, so I just click Next, and here we go.

The Platform has found the next version. I’m selecting it, making sure I got what I wanted, clicking OK, and the application is updated successfully. Updating the database application. And done.

This is now the brand new version of the 1C:Drive. But it’s too early to invite users back just yet. Let’s run the application first. And this first run is when the application performs all necessary data conversions and stuff like that.

Selecting a user. OK. More data preparation. Proceeding with the default settings. And done. Now the application is ready.

Of course, not every version of every application requires data setup during the first run. But it happens more often than not, so you better do it anyway.

Now. What do we do when we need to change the application ourselves, without updating to the new official version? Say, we want to add a new Catalog to the picture. How do we do that?

Well, the first thing we need to try is called an Extension. And this is how it works in a nutshell. Every application consists of a set of interconnected components: Metadata Objects referring to each other, pieces of source code, referring to Metadata Objects, etc, etc.

A new version of the app is always built on top of the previous one, so the new components fit the old ones. If I redesign any of the pieces, the next version components might not fit.

This is what happens when two independent developers (you and the application vendor) apply inconsistent changes: either the application cannot be updated to the latest version provided by the vendor or you cannot update the application the way you need.

But there is another option: extensions. The idea behind this is that you don’t change the application itself. Instead, you implement a separate patch changing or adding the functionality you need. Of course, it’s not a stand-alone fully-independent add-on or anything of that sort. It needs to fit into other components. It just lives separately and doesn’t replace anything. Until the runtime. As soon as the app starts, the extension patches it, overriding some of its functionality, so users work with your version of the app. When you stop the app, the extension disconnects and the original application stays unchanged. It means that you can easily update it to the next vendor’s version. It also means that the new version can bring along some changes incompatible with your extension. In this case, your extension won’t be able to attach to the application at runtime, and the original vendor’s version will run instead.

OK, let’s try the extensions hands-on. Let’s say I want to add a new Catalog to the picture. But instead of adding it like this, I’m going to this Extensions form and creating a new extension. Now I can open it. And this is what it looks like. Reminds of anything? Of course it does. It’s just an empty application tree ready for us to start implementing whatever we want.

So, I’m going to the Catalogs and adding a new one, like this. Now I need to make it visible in the command interface, which requires including it in a Subsystem. I could create a Subsystem in the Extension, like this, but I want to use the Sales subsystem belonging to the main application.

So, I’m going there. This is the Subsystem I need. And this is what I do. Right-click to open the context menu, Add to extension. And now we have the Sales Subsystem, basically, inherited by the extension we are working on. OK. Let’s include our Catalog to the Subsystem and check if it’s to be shown in the command interface, which it is.

Now. We also need to make the Catalog accessible by users, which requires including it into one of the roles. The Designer has already created this Role for us. And the Role already has full access to the Catalog. So I could just add it to the Administrator user, like this. But this is what happens if I try to run the app afterwards. This is not the Platform error message. This one is from the application, as you can see here. This DefaultRoles property mentioned above lives down here in the extension properties, and the application doesn’t want us to use some unknown roles (probably for security reasons).

So, I’m clearing this property up like this, going to the main application and grabbing this FullRights role for us to use. Now let’s give this role access to our catalog, save the extension and try to run the app. OK. I’m going to the Sales subsystem, and this is our new Catalog over here. Clicking it. And now I can fill it with all that very important data I’ve got.

Great. Now. The extension gets merged into the main application at runtime, so you can control it from the 1C client using this standard interface. Now it’s on. I’m turning it off. Reloading the application. And My New Catalog is no longer here. And the best part? The main application remains unchanged, so when I need to update it to the latest version I just do it.

But can we really patch the app all we want without ever impacting its updateability? Well, you didn’t expect this to be that simple, did you? Because, there are some limitations when it comes to extensions.

For example extensions do not support adding new Constants. So, if I really need it, I have to go and add in to the main configuration. And this is how it’s done. 

First of all, I need to go to the support options and enable any modifications at all. Now I can select any object and set its personal modification mode. The first option does not allow me to change the object at all. The second one lets me to change it with the possibility of merging my changes with the vendor’s ones later on. And the third option completely disables new official versions update for this object.

So, what do we need to do to add a new Constant? We need to unlock the root node of the application - the place where the list of the Metadata Objects lives. So, I’m going in and selecting the second option like this. Now I can add new Metadata Objects, so I’m adding my constant to the main application just like this.

Now. What will happen when I try to update the app to the new vendor’s version? Let’s see. And here is the application merging interface. This the constant we just added. It exists in our version but not in the new vendor’s one. This unticked checkbox means that the Platform suggests not doing anything about it, which is exactly what we need.

Down here are some changes brought to the table by the new vendor’s version. These selected checkboxes mean that the Platform suggests adding these changes to our application. Looks perfect for me, so I just click Execute, and here it is - the application merged from two different versions: mine and vendor’s one.