Transactions¶

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.

Transactions

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="transaction-info-view-wrapper">
    <div class="row">
        <div class="col-xs-12 col-sm-6 transaction-info-section">
            <div class="transaction-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="transaction-info-label">Seller name</div>
                    <div class="transaction-info-value">${sellerName}</div>
                </div>
                <div class="col-xs-12 col-md-4">
                    <div class="transaction-info-label">Buyer name</div>
                    <div class="transaction-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="transaction-info-value">
        <div class="transaction-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)

Important

If the elements contained in the transaction XML specify a file:// URI then the file path MUST be contained in an allowed download location. This is for security reasons. The configuration property: p6.service.transaction.allowed.document.paths is used to define the list of allowable download locations Defaults are: ${P6_DATA}/resources/documents and ${P6_DATA}/tmp

Display a transaction

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.

Edit a transaction

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¶

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:

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>

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>

Note

All permission names and uses are listed for Transactions and Documents.

Scripting¶

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