In the censhare Clients Admin mode, the Admin menu shows additional tools for debugging and advanced logging.


Log Preferences

Advanced log configurations can be configured by navigating to the File menu > Preferences > Logs... The dialog is split in the following three main sections:

  1. General - Allows the user to define various levels of logging for VFS, the Server and the Client
  2. XML-Protocols - Different protocols for generating XML logs for different Client and Server actions
  3. Output - The location where the log output will be generated

In this article, we will be working with the output set to Window, which prints all logs in a new window in the Client. The log window consists of the three following tabs:

  • Logs: Relevant Client Logs
  • XML Logs: The XML logs of the last executed actions. This tab consists of the three highlighted areas below:
    1. The navigation buttons allow you to move between the different steps and relevant logs of an executed action
    2. The type of protocol and relevant state/communication information
    3. The full XML log content
  • Server Logs: Relevant logs coming from the server-side

XML logging

The XML logging allows the Client to generate XML-related logs based on various XML protocols that correspond to different areas of the Client. In more detail:


  • RMI Communication - Displays step by step the relevant RMI communication type that was used to execute a desired action. The exact RMI communication type of each step is stated in area (2) and the XML content of the execution is displayed in area (3) of the XML logs tab. Example: Searching in the asset query window for an asset-based on its ID:

    • Step 1

      • RMI communication: [RMI:query] execute(data) [asset.query]

      • XML content:

        <query [...]>
 <condition name="censhare:text.meta" value="{assetID}"/>
 ...
</query>
        XML

    • Step 2:

      • RMI communication: [RMI:query] result(result) [asset.query]

      • XML content:

        <result xmlns:corpus="http://www.censhare.com/xml/3.0.0/corpus">
<asset [...]>
...
</asset>
</result>
        XML

  • Layout Communication - This protocol records the communication between the Client and InDesign and generated detailed logs based on actions that were performed on the layout.

Example: Communicating a geometry update

<layout-message xmlns:aic="http://ns.adobe.com/AdobeInCopy/2.0/" xmlns:censhare="http://www.censhare.com/xml/3.0.0/censhare" xmlns:corpus="http://www.censhare.com/xml/3.0.0/corpus" xmlns:new-fct="http://www.censhare.com/xml/3.0.0/new-fct" xmlns:new-val="http://www.censhare.com/xml/3.0.0/new-val">
  <commands>
    <command filepath="/14467/InCopy Editor Preview Layout.indd" hide="false" method="open" readonly="false" skipaskuseprefs="true" skipmissingfonts="true" suppresserrors="true" usedocprefs="true"/>
    <command expand="geometry" key="k0" method="report" structure="structure" uid="Df"/>
  </commands>
  <documents>
    <document key="k0"/>
  </documents>
</layout-message>
XML
  • Layout Events - This works similarly to the Layout Communicator protocol but instead it logs all events that occurred on a Layout asset via the InDesign plugin interface.

Example: Placement change

<report>
  <events>
    <event type="placement-change">
      ...
    </event>
  </events>
  <plugin application="InDesign" [...]/>
</report>
XML
  • Layout Document Validator - This protocol is triggered by updating/creating layouts, where the layout document is validated for its correctness against the asset element structure. Enabling this protocol will output the full asset XML structure of a Layout within all of its steps and changes of the document validation procedure.
  • Metadata Mapper - This protocol works in combination with the RMI communication protocol and provides the relevant xml log feedback when the metadata mapper command is triggered upon image import.
  • Server Events - The executed action displays the equivalent server event information.

Example: Creating a duplicate asset

<event-queue>
   <event ccn="0" method="change-asset" param0="22422" param1="0" param2="-2" [...] target="AssetEvent"/>
   <event ccn="3" method="change-asset" param0="22422" param1="1" param2="0" [...] target="AssetEvent"/>
   <event ccn="1" method="change-asset" param0="22423" param1="1" param2="0" [...] target="AssetEvent"/>
</event-queue>
XML
  • Server Events RMI - Similarly with the Server Events protocol with the addition that this protocol includes all relevant RMI communication information in area (2) in the XML logs tab.
  • XML Editor - This protocol is triggered by simple actions which when executed cause the user interface (e.g: dialogs and components) to reload. This protocol can work very well in combination with the XML Editor test tool, where dialog customisations generate detailed logs from the component level to the actual asset metadata. Similarly to the RMI Communication protocol, this protocol outputs the type of [XMLEditor] modification in area (2), as well as the XML content of the modification in area (3).

  • Asset Transaction - This protocol logs the asset XML at each state of a triggered transaction (e.g.: asset checkout). At each step, the protocol indicates its current state (areas (2) and (3)) and the status of the state (area (2)). Example: Checking out an asset:

    • Area(2) [AssetTransaction] SETUP done

    • Area(3):

       <asset-transaction [...] state="setup">
     ...
 </asset-transaction>
      XML

  • Cached Tables - When activated, this protocol listens to changes that occurred to one or more cached tables and generates the relevant logs based on the new changes.