18.104.22.168 base services fix pack implements a usability enhancement that provides Maximo Integration Framework (I-F) with functionality to include and receive attachments as part of an XML message payload.
The 22.214.171.124 base services fix pack provides functionality enabling the inclusion of attachments within an XML message when an object (such as PO or WO) is sent out, and supports the saving of attachment data when the inbound message includes an attachment within the XML message. Support for attachments also include data that is sent and/or received using flat file or interface tables.
To support attachments, the DOCLINKS object must be included in the object structure. When adding the DOCLINKS object to an object structure, the application will automatically include all the non-persistent fields of this object. For existing object structures (customers running pre-7116) with the DOCLINKS object, these new columns will have be configured to include the non-persistent columns. Existing customers who currently use the DOCLINKS object in their object structures can continue to do without providing the attachment. In this case the attachment must be moved manually and the integration only supports the creation of the DOCLINKS object and not the attachment document itself.
A new non-persistent column, documentdata, will be the column that contains the attachment data. This column is a type BLOB and the data in the message is base-64 encoded.
When the DOCLINKS object is included in an object structure, the attachment data will be sent as part of the outbound message. For Inbound processing, if the documentdata field contains attachment data, it will be saved as an attachment in a manner that is comparable to saving an attachment from an application. If the same attachment is sent multiple times, a new attachment file will be generated (it does not replace the previously sent file).
When using the event-based Publish Channel in Maximo, the linking of an attachment to a Maximo object (such as a Work Order or PO), may not trigger an update to the top object of the object structure registered to the Publish Channel. Under this condition there is no integration message sent out of Maximo. For example, a user in the PO application attaches a document to a PO and saves, this would not trigger the PO integration event to fire and send a message via the Publish Channel. If the user did some other update to the PO Header data in addition to attachment update, then an integration event would fire and send an integration message via the Publish Channel.
In order to process attachments, external applications receiving XML messages with attached files will be required to execute a base64 decode action on the documentdata field; MIME metadata will enable the receiving application determine the file type provided as part of message payload.
By default the documentdata column is defined as a BLOB data type in interface tables. Using a SQL tool, this column needs to be dropped and re-added as a CLOB data type (or as a TEXT datatype on SQL Server). Once this is done, support for attachments will be available through interface tables. The interface table change must be done anytime you create and/or re-create an interface table.
Sample XML file:
Provided in this technote is a Purchase Order xml file that includes a text file as an attachment. Inclusion of the DOCLINKS object as a child of the PO object in the MXPO object structure is required before attempting importing the sample xml file.
|Systems and Asset Management||Tivoli Asset Management for IT|
|Systems and Asset Management||IBM Maximo Asset Management Essentials|
|Systems and Asset Management||IBM Maximo Enterprise Adapter|