Contents

3rd Party Application Integration

Method 1--User Control

Step 1

If you have a compiled library, place it in the website /bin directory.

 

 Step 2

Place your Web User Control file in a directory of your choice within the IIS Application.

Step 3

Standard Web User Control Referencing

In the CMS, you can embed your Web User Control in several page types.  For example, you could place it in a Static Page 

 

Alternative Web User Control Referencing

Alternatively you can use a WYSIWYG-safe tag that will be automatically translated into a Web User Control reference.

 

Example

< div id=”ctlRef” comref=”~/path/MyControl.ascx” runat=”translation” parameters=”Property=Value;Property=Value” > Descriptive HTML < /div >

Elements

id an irrelevant ID that can be used for CSS styling inside the WYSIWYG comref the path to the Web User Control parameters the Web User Control properties separated by semicolon

Step 4

Save and publish the page.


 

Method 2 – Shared Application Page

Step 1 – Same as Step 1 of Web User Control integration process.

Step 2

Create or Edit an existing Application Page. You can select a physical ASPX page that is existing, or enter the ASPX code directly.

 

Using an existing ASPX page, you must enter the relative path and filename. You can use the Friendly URL property to give your Application Page a URL matching the filename.

 

Step 3

Save and Publish the page.

Notes:

The CMS can execute 3rd party applications with path transparency by utilizing the Virtual HTTP Handler. There are some limitations to this implementation:

  • The 3rd party application must not be pre-compiled.

If you must run a pre-compiled application, you will need to mind the current execution path:

  • References to Web User Controls should be offset by the Application path, like so: ~/path/reference.ascx
  • Server.Transfer or Response.Redirect should be offset by the Application path, like so:
  • ~/path/page.aspx
  • All Pages are run from the ~/ContentCache/ path.

If you are using a single Content Place Holder control matched to a Master Page, then the CMS can directly assimilate the ASPX file. If this is not the case then you'll need to strip everything but the relevant control references and content that is to be embedded into the website layout.

If your application does not use a compiled library for the CodeBehind, then you'll need to enter a quirk reference:

< %@ Page CodeFile= "~/MyFile.aspx.cs" % >

Note the space after the =. This will prevent the CMS from automatically striping the CodeFile element during assimilation.

 


Method 3 – Isolated Application Page

Step 1

Create Virtual Directories in IIS under the ASP.NET Application. These directories should map back to the root website’s physical directories. The virtual directories that should be created follow:

Data

This is used for application data that the CMS Libraries use. This is optional, but it may contain javascript references.

PluginCache

This contains installed plugins.

Service

This contains a web service file, Notify.asmx

 

Step 2

Create a physical directory: ContentCache

This directory will need write/delete permissions for ASP.NET to manipulate physical files. Only files relevant to this specific IIS Application will be created here.

Step 3

Copy any libraries from the root website’s /bin directory that are to be used in the separate IIS Application. The image below displays the libraries that are most likely essential for your application:

 

Step 4

Modify the Application’s Web.Config file to use the CMS Session/Page handler. Add the MachineKey tag from the root website’s Web.Config file. This is used for domain-wide session handling:

< machineKey validationKey="X" decryptionKey="X"/ >

Under the System.Web tag, or a separate Location tag, add the CMS Handler. This is used for Friendly URL translation and Session population:

< location path="Path" allowOverride="false" >

< system.web >

< httpHandlers >

< add verb="*" path="*.aspx"

type="BryceWebGroup.CMS.Shell.Page.Translation.Handler,BryceWebGroup.CMS"/ >

< /httpHandlers >

< /system.web >

< /location >

Step 5

Register the Application in the CMS. Note that Send Service Notifications is checked. This tells the CMS to distribute application event notifications to this IIS Application.

 

Step 6

Same as Step 2 of Shared Application Page integration process.

Step 7

Save and Publish pages within the Application.


Method 4 – Integrating with ASP.NET 1.1

Step 1

Modify the Web.Config file in the IIS Application by adding the following application setting:

< appSettings >

< add key="CmsImpersonationUrl" value="http://www.mywebsite.com/page.aspx " / >

< /appSettings >

The CmsImpersonationUrl property should be the address to a page to appear as.

Step 2

Copy the integration library into the IIS Application’s /bin directory:

 

Step 3

Modify the Global.asax file in the IIS Application:

protected void Application_BeginRequest(object sender, EventArgs e)

{

BryceWebGroup.CMS.Integration.NET11.Global.Begin();

}

protected void Application_EndRequest(object sender, EventArgs e)

{

BryceWebGroup.CMS.Integration.NET11.Global.End();

}

Notes:

All pages in the application will appear as the page specified. The original application output will be placed in the content area. Because of this the application output should be limited to only the content output and not the additional HTML head and body.


Method 5 – Integrating with other scripting languages

Integration with other server-side technologies is made possible using a special set of comment tags within the HTML that the CMS outputs. By performing an HTTP Request in a language such as PHP, you can download the HTML output from a CMS Page and parse the beginning and end areas then output those inside the scripting environment.

The output from the start of the Page to the beginning of the content is denoted by this tag:

< !--$EmbeddedPage.Integration_BEGIN$-- >

The output from the end to this tag marks the portion that follows the content output:

< !--$EmbeddedPage.Integration_END$-- >

Using these markers it is possible to extract the relevant HTML from a normal page output to skin external applications, even in other server-side languages and technologies.

The amount of code for a task like this with a language such as PHP or Perl is very small, enabling a simple integration solution.