Service Manager allows requests with no href or content-id

The reason HPE Service Manager allows requests with no href or Content-ID is that with some tools and toolkits it is difficult to arrange for the unique id of an attachment part to be the same in the XML as in the binary attachment part. Though this is trivial when using .NET, when using Axis, the Java code would generate a unique cid value in the MIME message part dynamically during message serialization. Unless you write code to set up a handler to participate in serialization (via a callback), it is impossible to match the value in the XML to the value in the MIME message part. To prevent these problems, Service Manager:

• Relaxed the schema such that href was not strictly required (use=optional).
• Added an alternative, optional attribute called Content-ID, which is used instead of href when serving responses containing attachments to Axis clients.

• Added code to try to guess the href value that should be present in the XML, if it is missing. If we are processing the Nth <attachment> element (the Nth DOM Node within the set of DOM children for the <attachments> element, where the <attachment> element has neither an href nor a Content-ID attribute), Service Manager tries to look at the attachment part with the same index value to check whether the name, length, and type match. If the number of DOM Node children under <attachments> does not match the number of attachment parts, Service Manager cannot process the attachment. It prints the following error in the sm.ini file:

  Error: unable to match incoming add attachment request 2 with no href

  attribute to an attachment part 

  This message says “attachment request 2”, which seems to be incorrect; because there is only 1 <attachment> element, it should apparently be “attachment request 1.” However, the attachment element is the second DOM child node of <attachments> due to the white space text present as DOM child node 1; the first child node of <attachments> is white space that may be ignored.

  The workaround is either do not serialize with pretty-printing (such as adding white space nodes to make the XML easier to read for the human eye) when sending requests to Service Manager, or write code that ensures that requests containing attachment operations have either an href or Content-ID attribute on the <attachment> element.

  Supported attachment types in Service Manager are MIME and MTOM. We often get the question if the consumer does not support these attachment types, if the SYSATTACHMENTS file can be exposed to get the attachments out of Service Manager. This is not supported. The attachments are compressed and cut into <=32K pieces and cannot easily be read from an outside source. A workaround that customers use frequently is receiving the attachment with the parent record, for example via a RetrieveIncident request, and then transforming it into base64 and sending to the consuming application where it can be transformed into the required format.