Skip to content

Views

The views service allows creating and maintaining views, which are XML files configuring how Transactions and Workflow Tasks can be searched and how the results are organized and displayed.

In a view, you can add, update, specify and sort the searchable fields that will be displayed in the Search Panel and viewable fields that will constitute the columns of the data grid displaying the results of the search.

Sample display

Sample display

For more information about the user interface, read the guide Views user interface.

Header fields

<View>
    <SmartTags>
        <TransactionType>TransactionInfo/TransactionType</TransactionType>
        <TransactionFormat>TransactionInfo/TargetDocumentFormat</TransactionFormat>
    </SmartTags>
    <DataType>TransactionInfo</DataType>
    <DataModel>TransactionInfo</DataModel>
    <DataPartition>TRANSACTION</DataPartition>
    <ReprocessRouteUri>direct:p6router.p6_demo_Dispatcher</ReprocessRouteUri>

SmartTags

SmartTags are used in conjunction with URI-typed viewable fields and specific types of scripts.
They can be leveraged to provide a nice HTML display of a source content that may otherwise not be very user friendly.

For example, say you may want the User Interface to render a nice display of Quote in UBL format (UBL is a royalty free library of XML business documents). In that case, TransactionInfo/TransactionType is Quote and TransactionInfo/TargetDocumentFormat is UBL.
You need to combine a definition of SmartTags like the ones shown above, the insertion of a viewable field like the one below: 

<Viewable>
    <Name>Document</Name>
    <Description>
        <EN>Document</EN>
        <FR>Document</FR>
    </Description>
    <XPath>TransactionInfo/TargetDocumentURI</XPath>
    <Type key="View_Document_${TransactionType}_${TransactionFormat}">URI</Type>
</Viewable>
…and a script with a name that matches the pattern defined in the key attribute of the the Viewable/Type tag. So, with the sample SmartTags and Viewable section shown above, you will have to have a script named View_Quote_UBL.

When some Quote transactions will be listed as a result of a search on Transactions, the ‘Document’ column will display a ‘View’ button. If you click on this button, you will then see the display as configured in the View_Quote_UBL script.
Note that if there is no such script or if the key attribute is missing in the Viewable/Type tag, the XML file will be displayed.

DataType, DataModel and DataPartition

The DataType tag defines the type of item to be viewed. The DataModel tag is where the data model of the item to be viewed is referenced. The DataPartition will normally be TRANSACTION (for transactions and workflow tasks). It could potentially also be LOGS or TABLE_DATA (if there was a need to show logs or table data as transactions).

Reprocess Route URI

To allow the Transactions user interface to reprocess transactions using the P6route component, you must add the endpoint URI of the route definition to send the transaction for re-evaluation. This is done using the element ReprocessRouteUri in the XML configuration.

Example

<View>
    <Name>Transactions</Name>
    <Description>
       <EN>Transactions</EN>
    </Description>
    <DataType>TransactionInfo</DataType>
    <DataModel>TransactionInfo</DataModel>
    <ReprocessRouteUri>direct:p6router.Hub</ReprocessRouteUri>
</View>

Key(s)

You may define the keys of the items the view will handle.

<ListOfKeys>
    <Key>
    <Name>Id</Name>
    <Description>
        <EN>Id</EN>
        <FR>Id</FR>
    </Description>
    <XPath>TransactionInfo/Id</XPath>
    </Key>
</ListOfKeys>

Searchable fields

To customize the behavior or the Transactions and Workflow Tasks UI search behavior, you need to edit the view XML definition.

Example of a searchable configuration

<View>
     <ListOfSearchables>
        <Searchable>
          <Name>TechnicalStatusCode</Name>
          <Description>
             <EN>Technical Status Code</EN>
             <FR>Code Statut Technique</FR>
          </Description>
          <XPath>TransactionInfo/TechnicalStatusCode</XPath>
          <Type>String</Type>
          <Default>Error</Default>
          <Choice>Acknowledged, Error, Missing attachment(s), Sent</Choice>
       </Searchable>
    </ListOfSearchables>
 </View>

Note

All possible statuses shall be listed in the searchable definition, as a multi-choice field.

For example, the TechnicalStatusDate should be set as a searchable, so users can search all transactions with a Technical Status updated at a particular date or during a period.

Note

By default, every Searchable is supposed to be indexed. If you want to disable that feature for a specific Searchable just add the indexed="false" attribute to the Searchable node.

Display of the fields

Searchable fields shall be ordered in a way that combines logic and efficient Portal display (multi-choice searchable fields shall be either on the same row or in the first column(s) of a row).

Example of inefficient Portal display

The first two search fields are not stacked upon one another.

Searchable fields

<XPath>

The XPath used to evaluate the search of the XML document.

If the <Type> isWords and the <XPath> element is repeated the underlying search logic will be changed from an AND to an OR.

For example:

... AND ( xpath1 CONTAINS "Error" OR xpath2 CONTAINS "Error" ) AND ...

<Type>

The available types are: - Words - RangeOfDates - RangeOfMillis - String - CaseInsensitiveString - OrgPath - Flags - Padding - InList

Details of the behaviour of each searchable type can be found here

<Default>

This is a default String value that will be placed in the search field. This value is only a default and can be modified or over-typed.

<Choice>

This element contains a comma separated list of possible String values. The presence of this element causes the text input field to be changed into a combo box control with the given <Choice> values as options.

Single select choice

An empty value (just a comma) is often useful to allow the field to be set to blank or null.

Note

By default the combo box control is editable.

Select multi items

Using additional attributes it is possible to change the standard <Choice> combo box control to a multi-select list control. This control will allow multiple items to be selected or de-selected.

Often when multiple items are selected, the server processing will require them to be delimited with certain characters. By default items will be delimited with commas. More typically for systems with PostgreSql databases the delimiter character should be the pipe |.

For example:

<Searchable>
   <Name>TechnicalStatusCode</Name>
   <Description>
      <EN>Technical Status Code</EN>
      <FR>Code Statut Technique</FR>
   </Description>
   <XPath>TransactionInfo/TechnicalStatusCode</XPath>
   <Type>Words</Type>
   <Choice multi-select="true" multi-select-delimiter="|">Acknowledged, Error, Missing attachment(s), Sent</Choice>
</Searchable>

Display a list of choices

When you need to display a list of choices but want to be more descriptive in the list displayed to the user, this element can be used in addition to the <Choice> element.

This comma delimited list contains a display value that corresponds to the query value contained in the <Choice> list.

For example:

<Searchable>
    <Choice multi-select="true">SNT,REC,ACK,PEND,</Choice>
    <DisplayChoice>Sent Invoices,Received Invoices,Acknowledged Invoices,Pending Invoices</DisplayChoice>
</Searchable>

This will show a multi select choice as follows:

Multi select choice

Disallow the typing of custom values

This applies to the none multi-select choice: the combo box control. By default this control is editable. This means that a user can type an additional value for inclusion in a query.

Adding the <Choice> attribute editable="false" will ensure that only those values present in the <Choice> list are selectable.

Restrict the height

By default a multi-select <Choice> will size itself to an 3-line height. To restrict the height of a multi-select <Choice> input cell, add the field-line-height="xxx" attribute. Where xxx is the number of lines to display in the field.

Warning

The user could scroll the multi-select-list to access all available values.

Viewable fields

To customize the search response format, you need to edit the view XML definition.

Example of a viewable configuration

<View>
    <ListOfViewables>
        <Viewable>
            <Name>LoadDate</Name>
            <Description>
                <EN>Load Date</EN>
                <FR>Date de création</FR>
            </Description>
            <XPath>TransactionInfo/CreationDate</XPath>
            <Type>Date(yyyyMMdd'T'HH:mm:ss.S z)</Type>
            <Display>
                <hidden>true</hidden>
                <textAlign>right</textAlign>
                <textColor>red</textColor>
                <columnWidth>250</columnWidth>
            </Display>
        </Viewable>
    </ListOfViewables>
 </View>

Description

Fields that are both searchable and viewable may have different descriptions to accommodate column width. For example, description may be Document Type as searchable but only Doc. Type as viewable, same with Document Number vs. Doc. Number.

The description of SURI typed viewable fields shall not contain the word View or Display but only what they allow to view/download (often Source, Document, Attachment…).

Type

This is a display type inference that is used by a user interface to render the viewable

Supported types are:

  • Date([format]) : a JDK date format string. E.g. yyyy-MM-dd'T'HH:mm:ss.S z
  • String : a text string
  • ReferenceString : text to be used as reference only and not displayed
  • URI : a URI
  • SURI | SDOC : a Smart URI/DOC (see below)
  • Flags : transaction flags (see below)
  • I18nStringMap : an i18n Map of Strings
  • ItemLink : a link to a transaction (see below)
  • WorkflowStep : details of any workflow step that created this transaction

Types may also use the following attributes:

  • key : used as additional argument to SURI/SDOC
  • hidden : available to the user interface but not to be displayed

Display

This is how should be displayed a viewable in a grid. The Display node is optional.

Supported and optional sub nodes are:

  • hidden : Hidden column - default is “false”
  • textAlign: Text alignment (left, center, right) - default is “left”
  • textColor: Text color - default is “#3a3a3a”
  • columnWidth : Column width (in pixels) - default is “150”

It is possible to create Item links, i.e. the ability to navigate between specific transactions (items, technically speaking) in the Transactions Portal UI.

Item Link

Once a link is created, a View button is automatically displayed in the transactions list and clicking on the button will open the linked message.

In the transaction you want to link from, create an XML element containing the details of the transaction you want to link to, for instance:

<itemlink>
   <view>Customer Portal</view>
   <id>Invoice_Z5931030123_64711a55-f8ed-4919-abbb-2f2961ee8725</id>
</itemlink>

The name of the XML element, itemlink in the example above, does not matter, however this element must contain at least:

  • one view element which contains the name of the view which will be used to fetch and display the linked transaction
  • one or more id elements which contain the linked transaction ids

The XML configuration of the view of the transaction you link from must contain a viewable of type ItemLink with an XPath pointing to the XML element above.

<Viewable>
    <Name>itemLink</Name>
    <Description>
       <EN>Transaction</EN>
       <FR>Transaction</FR>
    </Description>
    <XPath>/TransactionInfo/itemlink</XPath>
    <Type>ItemLink</Type>
</Viewable>

Flags

The XML configuration for the view supporting flags must be updated with a new viewable of type Flags:

<Viewable>
    <Name>Flags</Name>
    <Description>
         <EN>Flags</EN>
         <FR>Flags</FR>
    </Description>
    <XPath>TransactionInfo/Flags</XPath>
    <Type>Flags</Type>
</Viewable>

For a transaction to be flagged, the XPath in the viewable must exist in the XML of the transaction.

Thus, to flag existing transaction, all transactions will need to be first reprocessed to insert the appropriate element with an empty JSON Object as value {}, so that they can be flagged.

Smart Views/URIs

Smart View (SURI) refers to the formatting and display of file content referenced via a URI in a Platform 6 document or the Platform 6 document itself.

More information in this section.

XSD validation

The structure of the XML is checked using a XSD.

To help you develop your application you can use that XSD to validate the code in your IDE (ie. if you are using P6Sync). Simply add the attributes to the root element as shown bellow:

<View  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="https://documentation.amalto.com/platform6/latest/reference/built-in-services/views/views-guide/resources/View.xsd">
    ...
</View>

The documentation displayed in the XSD has been extracted from that page.