Transactions Guide

Glossary

A transaction type or concept defines the transaction XML structure - the most common transaction type / concept is TransactionInfo but there are others like Logging Event, Update Report, etc.

A transaction is an XML document stored in the database.

A document is either a structured document received or sent to a trading partner (e.g. a PIDX invoice) or an attachment, such as a PDF. It is attached to a transaction.

A view is defined in the Views service and determines, for a specific transaction type, the searchable elements and the viewable elements within the transaction.

Features

Through the Transactions service UI, you can start a new search with different search parameters.

The search parameters and the values of the response are associated with the selected view. They are customizable in the Views service.

Warning

If you have updated a view, you need to restart the Transactions service using the service lifecycle header to take the changes into account.

When you double click on a transaction, the server executes a script named [VIEW_APPKEY].View_[VIEW_NAME] and returns the HTML content of the transaction enriched with its values.

The script takes the XML and converts it into HTML. Here is a sample of a script.

// Get the slurped xml
def transactionInfo = p6.pipeline.getXml 'xml'

// Values
def businessDocName = transactionInfo.BusinessDocName.text()
def businessDocNumber = transactionInfo.BusinessDocNumber.text()

def sellerName = transactionInfo.KeyValue.find{it.Key == "Seller Name"}.Value.text()
def buyerName = transactionInfo.KeyValue.find{it.Key == "Buyer Name"}.Value.text()

def html = """
<div class="message-info-view-wrapper">
    <div class="row">
        <div class="col-xs-12 col-sm-6 message-info-section">
            <div class="message-info-header">Transaction: <strong><span class="right-spaced">${businessDocName}</span> ${businessDocNumber}</strong></div>
            <div class="row">
                <div class="col-xs-12 col-md-4">
                    <div class="message-info-label">Seller name</div>
                    <div class="message-info-value">${sellerName}</div>
                </div>
                <div class="col-xs-12 col-md-4">
                    <div class="message-info-label">Buyer name</div>
                    <div class="message-info-value">${buyerName}</div>
                </div>
            </div>
        </div>
    </div>
</div>
"""

p6.pipeline.put 'portalHtml', html, 'text/html'

The returned portalHtml allows a customised display of a variety of values; transaction details: additional information, status, attachments, workflow history etc. If no view script exists or the script fails to return portalHtml you will only see the transaction’s XML.

Download of Attachments

The View script generated portalHtml can contain links like <div onclick="b2portal.transactionDownload(this)"> that will allow the user to download attachments.

Here is an example of the XSLT required to generate the portalHtml:

<div class="col-xs-12 col-md-6">                        
    <div class="message-info-value">
        <div class="message-info-file">
            <xsl:variable name="srcDocExtension">
                <xsl:call-template name="get-file-extension">
                    <xsl:with-param name="path" select="CurrentDocumentURI"/>
                </xsl:call-template>
            </xsl:variable>

            <div onclick="b2portal.transactionDownload(this)">
                <xsl:attribute name="class">
                    <xsl:value-of select="concat('ft-icon ft-icon-', $srcDocExtension)"/>
                </xsl:attribute>
                <xsl:attribute name="data-extension"><xsl:value-of select="$srcDocExtension"/></xsl:attribute>
                <xsl:attribute name="data-ids"><xsl:value-of select="$msgId"/></xsl:attribute>
                <xsl:attribute name="data-uri"><xsl:value-of select="CurrentDocumentURI"/></xsl:attribute>
                <xsl:attribute name="data-content-type"><xsl:value-of select="CurrentDocumentContentType"/></xsl:attribute>
                <xsl:attribute name="data-view">{{viewName}}</xsl:attribute>
            </div>

            <xsl:variable name="srcDocFileName">
                <xsl:call-template name="get-file-name">
                    <xsl:with-param name="path" select="CurrentDocumentURI"/>
                </xsl:call-template>
            </xsl:variable>
        </div>
    </div>
</div>

Warning

The function b2portal.messageDownload() is available for backward compatibility only and is now deprecated. b2portal.transactionDownload() should now be used. (messageDownload requires the older message permissions whereas transactionDownload requires the current transaction based permission sets)

You can also edit the transaction XML definition. It is validated on the save by the associated data model.

The transaction is not saved if the XML is invalid.

Finally, in addition of printing, deleting and refreshing, a transaction can be reprocessed using the Platform 6 routes. Have a look at the Views service guide section to see how a transaction can be routed.

Permissions

Transactions

A permission transactions=allow(...) must be explicitly set for any user that wishes to access transactions and/or documents; the transactions=* permission is not sufficient.

By default, access to all transactions is denied with the transactions=allow("FILTER,FILTER,...") permission.

Multiple instances of FILTERS, separated by comma may be specified. FILTER is either:

• *: access to all transactions is granted
• "VIEW_NAME"(FILTER_EXPR, FILTER_EXPR,...): access to the VIEW_NAME view is granted under the condition(s) specified by the FILTER_EXPR.

Accessing all transactions under the VIEW_NAME view

Set FILTER_EXPR to *. For example: transactions=allow('MyView'(*))

Filtering transactions based on the transaction content in the VIEW_NAME view

Set FILTER_EXPR to "SEARCHABLE_NAME"="VALUE" where:

• SEARCHABLE_NAME is the name of a searchable in the XML definition of that view
• VALUE is the value to filter that searchable on

A special VALUE, %USER.EMAIL% will be auto-expanded to the current user email address allowing the set-up of automatic filtering of messages based on the user email. The email must be present in the message, at the XPath location indicated in the XML definition for the view.

For example: transactions=allow( "Invoices and Exceptions" ( "UserEmail" = "%USER.EMAIL%" ))

Filtering transactions based on the position of the user in the organization tree

Set FILTER_EXPR to either UNIT or BRANCH where:

• UNIT means transactions dispatched to the same organization node as the user, and this one only.
• BRANCH means transactions dispatched to the same organization node as the user, and any child of this node.

To dispatch a transaction to an organization node:

1. The transaction must contain an XML element containing the full path to an organization node (the name of the XML element itself dow not matter).

   Example: <OrgPath>/Demo/Portals/Customer Portal/Customer A</OrgPath>

2. The XML definition of the VIEW_NAME view must contain a searchable of type OrgPath with its XPath pointing to the element containing the organization node path in the transaction.

   <Searchable>
       <Name>OrgPath</Name>
       <Description>
           <EN>Organizational path</EN>
           <FR>Chemin organisationnel</FR>
       </Description>
       <XPath>/TransactionInfo/OrgPath//text()</XPath>
       <Type>OrgPath</Type>
   </Searchable>
   

All transactions permissions

All permissions related to transactions go with the feature transaction (see the permissions anatomy section).

Permission scope	Description
transactions=view	The user can search transactions (within the filters specified in allow) and view the content of the transactions.
transactions=edit-form	The user can edit and save a transaction, only if a form is provided (formjs for the moment) and only via the form display (no access to XML source).
transactions=edit-all	The user can view, edit and save a transaction. Changing the values of the element that constitutes the keys of the transaction will currently create a new transaction (it is an upsert).
transactions=reprocess	The user can trigger the reprocessing of a transaction.
transactions=delete	The user can delete a transaction.
transactions=*	The user can view, edit, reprocess and delete a transaction.

Documents

Permissions related to documents go with the feature documents or transactions.

Permission scope	Description
transactions=view OR transactions=edit-form OR transactions=edit-all OR documents=view	The user can view the content of a document.
documents=edit-form	The user can edit the document, only if a form is provided (formjs for the moment) and only via the form display (no access to source / raw content).
documents=edit-all	The user can edit a document via a form if one is provided or its raw content directly.
documents=*	The user can view and edit a document.

Scripting

You can manage transactions with the Scripts service using the transaction DSL.