The plugins folder

The most important requirement of the plug-in architecture is that all plug-ins should exist as subfolders inside the plugins folder. This plugins folder is available inside your MicroStrategy Web installation folder as shown below.

 

pluginsfolder.gif

 

Based on your customization requirements, the Web Customization Editor automatically creates plug-ins inside this plugins folder. Each plug-in corresponds to a single customization task. A plug-in subfolder can contain a single or a combination of several files (such as configuration files, JSP or ASP.NET files, etc.) that contain software code specific to the customization. This software code is then virtually merged into the appropriate file or files (such as configuration files, JSP or ASP.NET files, etc.) when the application server hosting MicroStrategy Web is restarted.

 

Consider a customization scenario that requires a code change to the Page Configuration file, pageConfig.xml.

 

Note: For detailed reading on how the customization method compares with the current version of MicroStrategy Web and version 8.x of MicroStrategy Web, refer to Comparing the New Customization Method.

 

Before the plug-in architecture was available in MicroStrategy Web, the code responsible for accomplishing the above customization had to be inserted into a copy of pageConfig.xml. Thus this copy contained the customization-specific code along with the rest of the existing default code. Additional files such as web.xml had to be modified to make sure MicroStrategy Web used the copies of the modified files. This process, even though it isolated the customized files in a separate folder, still made it difficult to identify the customization changes from the rest of the default code.

 

Now for the same customization scenario with the plug-in architecture, the Web Customization Editor creates a plug-in (subfolder inside the plugins folder) that contains pageConfig.xml. This pageConfig.xml does not contain anything other than the code that helps achieve the customization. When the application server is started, MicroStrategy Web looks into the plugins folder and identifies the existence of pageConfig.xml. It then deploys the customization by virtually taking the software code from these two files and merging it into the out-of-the-box pageConfig.xml that is available in the WEB-INF\xml folder.

 

This separation of the customization code changes from default code from MicroStrategy Web is the hallmark of the plug-in architecture. Since the plug-in is independent, MicroStrategy Web can successfully run with or without the existence of the plug-in.

 

Additionally, the plugins folder can contain several plug-in subfolders that each correspond to separate customization tasks. The Web Customization Editor creates these plug-ins (that is, plug-in subfolders) based on your customization tasks. Do not attempt to manually edit these plug-ins; always use the Web Customization Editor.

 

 

Note: Do not change the name of the customization plug-in once you have created it. There are several references (relative paths) to files within the plug-in that have the name of the plug-in in them. Renaming the plug-in will render those relative paths invalid and your customization will not work.