When you’re developing for SalesLogix Web in the Application Architect, there are three actions that a developer must use during the process: building interfaces, building the web platform, and deployment. For someone starting out with the Application Architect, the reasons behind each of these actions can be confusing. Even more confusing can be when one is used vs another. This post will attempt to explain these three actions and when/why they are used.
If you think about how the entities are used in code, you’ll know that it is always via it’s interface. Basically, an interface is a sort of “contract” that another class that implements the interface must abide by. The interface has no implementation code, it only defines what the implementing class must have. The reason why the entities in SalesLogix all implement an interface, and also why these interfaces are used to reference the entities in the AA and in code, is to provide a level of abstraction from the actual implementation of the entities. This way, when “future” SalesLogix can be deployed to web, windows, or mobile, the implementation of the entities can differ if needed yet all still implement the same interface, and the code that uses them via the interfaces will still work.
So, what does that have to do with using the Application Architect? Just as your own code will use the entities via their interface, the QuickForms and other areas in the AA will use the interface as well. When you make a change to an entity, such as add a new entity, or add/change a property or relationship on and entity, the rest of the Application Architect will not know about this change until you’ve built the interfaces – which will cause the interface to show the change you’ve made. If you add a new property to an entity and then want to add it to a QuickForm, the QuickForm designer won’t know about the new property unless you’ve rebuilt the interfaces.
As a rule of thumb, you should rebuild interfaces after doing the following:
- Add a new entity
- Add or change properties on an entity
- Add or change relationships for entities
Now, remember this: building interfaces is only needed if you want to immediately use an entity you’ve added or changed in the Application Architect. The whole purpose of building interfaces is to make an entity change immediately available for use in the Application Architect. If you’re not going to use that change in a QuickForm or something right away, then you don’t need to build the interfaces. As you’ll learn in the next section, building the web platform also builds the interfaces (so if you’re going to be doing that anyway, no need to take this step).
In newer versions of SalesLogix (I think this came in 7.2.1 or 7.2.2) the Application Architect will attempt to recognize when a build is required for the interfaces and will run the build for you. I don’t really like this since you’ll attempt something like open up a QuickForm, it looks like the AA has locked up, but what it is really doing is running the build interfaces step in the background, when it’s done it will open up the form. Instead, I like to do my own build of the interfaces when it is required.
Building Web Platform
When you build the web platform, what you’re essentially doing is getting the entity model ready for a web environment. All of the business rules and event code is compiled so it is usable by the entities, the QuickForms are converted to SmartParts (ASP.NET UserControls, ascx files), and so forth. This is a required step if you’ve made any changes at all in the entity model, that means entities, QuickForms, relationships, business rules, etc. Remember, this step also builds interfaces, so no need to do that too. Before a deployment can happen, this must occur first to prepare the entity model by getting it into a web usable format.
As a rule, you must build the web platform after you’ve done the following:
- Anything listed above in the building interfaces section
- Created/modified a QuickForm
- Created/modified a business rule, event code, or code snippet.
If you’ve changed anything in the entity model then you must do this step. Be clear about this, however, this is only needed with changes to the entity model only. Making changes in the portal manager, such as adding a SmartPart to a page, adding a new page, adding navigation menus, etc, are not part of the entity model, so there’s no need to build the web platform, only deployment.
The deployment is the step that pushes everything out to the website itself. The deployment process will check for the files that have changed and will push out accordingly. The deployment is needed after you do basically anything in the Application Architect to get the changes out to the website. There are some things you can do in the AA which only require a deployment with no builds or anything else. If the only changes you’ve are in the portal manager, such as adding a SmartPart to a page, changing where a SmartPart loads on a page or anything like that, then all you need to do is a deployment. No builds are needed. Make sense?
Yes, a lot to take in. Remember this:
- Make changes to entity model and want to use the changes right away, build interfaces (unless you’ll also be building web platform for other reasons)
- Any change to the entity model, build the web platform
- Any change mentioned in 1 or 2, deploy.
- Any change to the portal manager, deploy.
Worse case, it doesn’t hurt to to more than what is necessary. If a build ins’t needed and you do it anyway, it won’t hurt anything. However, you’ve realized by now that the build and deployment for SalesLogix web takes a long time. Anything to cut down on that time, and only perform exactly what is necessary is always helpful.