Technical Overview

Release 1.0 - ...

One of the core AIM tasks is the AIM scanning background process. This spider-like process scans data whenever content is added or updated, simply by requesting the item on the AIM channel.

DataModel

Rendering on the AIM channel produces an XML document with all outgoing AIM references, which are then stored in two separate locations:

  • Cross-references are stored in the ContentRelations table, using reserved ContentRelationTypes:
    • AIM
    • AIMS
    • AIMIF
    • AIMFI
    • AIMFF
    • TRANSLATION
  • External references (to resources not in the CMS) are stored in the ExternalReferences table using the ContentReferences table as cross-table.

External references storage model

The AIMState content field is used for housekeeping here: whenever the scan of an item is completed, the AIMstate field is set to Ready.

Scan Process

The AIM spidering process involves rendering items on the AIM channel, and is thus configurable en extensible by SXML site building. Building blocks include:

  • AIM macro
    Root macro for the AIM rendertemplate. Used to hold references collection during rendering and output it as XML
  • References macro
    Embeds items on given channels in AIM-mode (using the Request Command hid=AIM) and adds the relations found during rendering to the collection in the root AIM macro.
    Multiple calls are allowed to include channels on which the item renders and produces relations to other resources.
  • AIMScan macro
    Scans the item's raw data for references, such as HTML hyperlinks.
    Currently, the following references are detected by AIM:
    • HTML entities
      • href (BASE, A, AREA, LINK)
      • src (APPLET, BGSOUND, EMBED, FRAME, IFRAME, IMG, INPUT type=image, SCRIPT, XML)
      • background (BODY, TABLE, TD, etc..)
    • CSS entities
      • @import (CSS include)
      • url (CSS attributes)
    • XML entities 
      • xml-stylesheet
      • xsl:include
  • Several AIM helper Viper methods
    aim.addrequest(), aim.references.add(), etc...
  • Many AIM-aware macros and Viper methods
    Application, XLinks, SiteMap, Parents, Embed, EmbedUri, Siblings, ItemData, Html.Link(), Response.Redirect(), ItemData.Field(), etc...

A typical AIM RenderTemplate looks like this (1.3+):

Smartsite SXML CopyCode image Copy Code
<se:xmlprocessor xmlns:se="http://smartsite.nl/namespaces/sxml/1.0">
 <se:parameters>
  <se:parameter name="xml">
   <se:aim>
    <se:aimscan 
     error="{buffer.set(scanError, this.error.message())}" />
    <se:references 
     channel="{channel.defaultchannel()}" 
     error="{buffer.set(renderError, this.error.message())}" />
   </se:aim>
  </se:parameter>
  <se:parameter name="actions">
   <se:collection>
    <se:member query="//references">
     {sys.iif(buffer.exists(renderError), this.setattribute(renderError, $renderError) )} 
     {sys.iif(buffer.exists(scanError), this.setattribute(scanError, $scanError) )} 
    </se:member>
   </se:collection>
  </se:parameter>
 </se:parameters>
</se:xmlprocessor>

Cache- and state-invalidation

When content changes occur, Smartsite iXperion uses the SQL function fn_RecurseAIMDependencies() to collect the dependencies of the changes:

SQL CopyCode image Copy Code
select nr from dbo.fn_recurseAIMDependencies(?, 0)

The fn_recurseAIMDependencies() function collects the complete chain of AIM relations given one or more item numbers:

SQL CopyCode image Copy Code
select a.depth, a.nr, c.title from dbo.fn_recurseAIMDependencies(238, 0) a 
join vwContent c on a.nr=c.nr order by a.depth

Will return a list of all items directly or indirectly affected by changes to item 238.