In the 7.2 release of SalesLogix Web you were introduced to the Application Architect and the Virtual File System. Immediately there was a flurry of information being created and consumed, some correct and some incorrect. In the training department at Sage we have even had trouble deciding what to call certain parts of the product. Our main concerns are to remain consistent with what the developers or product management decide to call the pieces and to train you on these subjects as best we can.

So now we talk about the VFS

In the past I have referred to the VFS as anything related to my customizations. There was a table in the database named VirtualFileSystem, there was the project workspaces that contained one or more VFSs, and there was the potential to be working with an “exported VFS”.

I was wrong in a couple places, important places mind you, and I was not alone.

Say it ain’t so

Sorry but it is so. Here is how I remember it:

Before the SalesLogix Boot Camp I was talking to a developer about a subject we were covering. In the Boot Camp we were going pretty deep into about 25 topics and I needed to have some real details about “the VFS” as I called it. As we were talking this developer stopped me and said: “You mean the model?” and I said: “uh yeah, the model in the VFS” and we moved on. I hadn’t realized that my affirmative statement was actually completely wrong. The same situation happened the next day and I finally asked for an explanation of the differences in semantics.

But it didn’t stick

So Boot Camp came and we started in on the particular exercise that included “the VFS”. There were several discussions about what the VFS was and was not and what else it was to be called. We brought in the idea of a model (which was in the book in the correct form) and that seemed to raise more questions.

After all we had gone 2 years as a group calling this thing the VFS. Something had to change. This is where the LFS idea came from. Someone from our PSG group suggested it be called the LFS for Local File System when it is exported. Sounded good at the time and we talked a bit about it and moved on.

What are we left with now?

What we are left with now is three distinct ideas:

• The VFS
• The Model
• Project Workspaces

VFS or Virtual File System

The VFS is a table in the database. It is called the VIRTUALFILESYSTEM table. It is used to hold the Model as well as some user settings for the dashboard on the web. This was covered well in the videos and book from Boot Camp – available at the developers subscription.

The VFS is also used to refer to the system of storing items in the table called VIRTUALFILESYSTEM, but much less often.

The Model

The model is your actual work. It is a set of mostly xml files containing mostly meta data used to describe the stuff you see in Application Architect. There are files for every entity, every business rule, every form, and just about everything else. Portals are in there along with their definitions too.

Realistically it is a folder on your hard drive or stored in the VirtualFileSystem table. To me it is like the changes in a visual studio project without the csproj or sln files. Visual Studio .net can use that folder perhaps, but without the csproj files it is really just a collection of files.

Project Workspaces

So when you pull your Model into Project Workspace Manager it becomes a Project Workspace:

This is why LFS is such a bad term. You can have more than one Model on your “Local File System” which one is the LFS? The model is in a location, either the VFS or on the local hard drive or on a network share somewhere. In either case it is hardly usable outside of a Project Workspace. You can use it and we do in many videos in the developers subscription, but really we spend most of our time in AA making modifications.

Wow that is confusing just break it down for me

OK, so your are confused. Just do this:
Stop referring to your Project Workspace as a VFS. If you want to know where to place source control or how to backup your changes you need to know the working path of the Model. Is it in the VFS or on the hard drive or a network share?

Can you export your VFS? No. You export your model from a Project Workspace by right clicking a project and then “Add”:

Can you backup your VFS? Yes. Just like any other table ;) You use SQL Server to do this.

Oh you mean backup your model? Sure. Just use 7-zip like any other folder ;)

I see. You mean backup your Project Workspace? Sure. Right click the Project Workspace and backup and restore as needed.

“Wait!” he says, “I want to import the entities and stuff I have in an “exported vfs” into the vfs that is in my database.” and he has learned nothing from this post.

You can import the changes from one project into another – remember a project is a model loaded into Project Workspace Manager – from the C:\ or network share OR from the VFS. So right click your destination project (the one in the vfs probably) and import from another project. Then you can choose the Project that you want to import from – the one on the C:\ drive or network share.

While planning our SalesLogix deployment most administrators are worrying about where to put their sync server and how to open the ports for the website and soon they arrive at the “how do we let our developers do their work?” question. Some things to consider are:

• Do you have more than one developer?
• Do these developers have a machine that can handle a full SLX install sans sync/remotes?
• Do you have a staging server for the changes these developers will be making?
• How will you manage the integration of the changes made by these developers?
• Are you planning on using source control?

Most of the answers to the above questions should be yes. If you have more than one developer they should have a machine capable of running SalesLogix, SQL (Express), VS.NET 2008 and you should have a staging server or at least another deployment and setup on one of those machines for integration tests, a plan for managing those integrations and some sort of source control.

Let’s get started

First some nomenclature. At least one thing is commonly misrepresented by myself and many of the people I talk to. The VFS is a table inside the database. The Model is the changes you are going to be making – it is made of up of all of the xml files etc. Most of us call the model the vfs, but the model can be IN the vfs if you choose or exported.

To export or not export the model? I have asked several people in development and all agree – export the model from the vfs to the local file system. This makes compilation and deployment on the development machine faster and allows for source control to be applied. If you are a single developer working on a single project then perhaps you have a reason for leaving the model in the vfs, but probably not.

Now on the SalesLogix server you can have the model anywhere you like. Why? Because when you go to apply your changes to production you can either bundle the changes up from the staging server, copy the changes from project to project (exported project to project in the vfs in production) or backup the model on the staging server and restore it into the model in the vfs on the production server. You are not concerned in production about the time it takes you to build and deploy the few times you are required to do that in production.

Another great reason for leaving the model in the vfs in production is for backups. We are rather adept at backing up our whole database. This is something we have had to do a lot of in SalesLogix over the years so we have gotten accustomed to it. Doing this on the staging server and delivering the whole database to the client was another method. In either case you will export on the developers machines.

Apply Source Control

So now that you have your model exported from production you can get it on some network share and apply source control. We covered this in Boot Camp and it is also covered here. We used Git at Boot Camp and it is pretty awesome, but many of you already have a source control system in place. At this point you “apply” source control to that exported model. With Git this means creating a bare repo and pushing everything into it, with Subversion or others you have other options.

The only real trick is to use something that allows for optimistic locking. Take Visual Source Safe. The default source control for classic asp systems back before 2002 or so. It makes every file in the directory you control read-only. This causes problems with SalesLogix (and many other code systems) because we create new files, they are read-only and not checked out immediately, so then you get write errors. With something like Git you can create files and edit as you see fit and only at commit do you need to realize what you changed, apply a nice comment and then commit.

Just keep that in mind. Both Subversion and Git have their Tortoise UIs and we have videos in the developers subscription showing how to use Git and the PDF from boot camp is also available here.

Now bring in the developers

So the developers have SalesLogix installed on their machines with SQL Express and Visual Studio (if you want it – I suggest you will). They do a pull from the repo to somewhere on their local drive let’s call it “C:\vfslocal” and we will refer to it as “vfslocal”.

The developer then opens Application Architect and probably has only one model in their project workspaces – it is the one from the database they have connected to. This database should be a copy of the production database. It can have a model in it, we just don’t care about it as developers – that is for administrators later on.

Right click on the project workspaces and add a new workspace pointing to the vfslocal you created. Build it and press the run button at the top of Application Architect. You need to have a deployment configured as default and debug to do this, but that is covered well elsewhere. If you do not have IIS installed – that is ok. Application Architect comes with its own development webserver that will be used.

Developers make changes, they commit locally and they push good code up to the repo on the share location. All is well.

When the developers push their changes to the shared repo they are forced to reconcile their changes. This means they cannot go home until they have used a merge tool to ensure their changes are integrated into the code. They really want to do this – that is how they share their work. If this step fails or has a problem and something is overwritten then the source control system has a method for “rolling back” changes etc.

Let’s QA something!

Your staging server will be used here. The point of this step is to get the changes out of source control and into a production like environment. So we do a pull or get from source control of the entire model. If you were choosing to not use source control at this point you would be asking your developers to bundle everything up and send it to you. Either way you gather all the changes, apply them to some model somewhere. For us that is going to be a model in the vfs on the staging server. We want it to be as close to production as possible.

How do we do that? On the staging server (or connected to it) we open Application Architect and create a new workspace pointing to the model we just pulled from source control. It should show in our project workspaces now. Click on the model in the vfs and tell it to import from other project and choose the project you just created. AA will then suck all of the changes from the source controlled model into the vfs.

What have you done?

You have taken the changes that the developers have pushed to the repo and pulled them locally to the C: drive of the staging server and then imported them into the vfs. You can now build and deploy and check for quality as you see fit.

You still need to get them into production, but production can be on the machine next to you or at a client site. At this point you can backup the model in the vfs and restore it to a client production machine, copy the whole database if there were data changes too or create a bundle of all the changes and apply it to production. The options are limited.

What not to do?

Do not place source control on the output files (C:\inetpub\wwwroot\slxclient). This makes no sense. If you want a copy of these files then use a deployment snapshot instead. This was also covered in boot camp and in the various classes offered at Sage.

Do not have more than one developer working out of the database (vfs). This will cause a problem. The easiest one is both developers open AccountDetails, one makes changes and the other just looks at it unaware of each other. Both press save. The LAST ONE to save get his or her changes in the vfs the other one loses their changes forever. It is just that simple. Export your vfs and apply source control. Two ways to not have that happen to you.

Here is a basic diagram of the process as I see it. I have verified this information with several good resources, but comments are welcome and edits may be made :)