This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
yes,we will do this if disabling the dialog is not enough. Or perhaps we will
strip the tags at saving, it's not decided yet what we will do.
Ewald
------------------------------
Have you considered using a processing class or and XML transformation to remove
the tags from the rich text data and push them as basic text?
Chris.
If you go the route of stripping the tags, be aware that the rich text editors also allow other non-printable ASCII characters as well. We discovered that some of the long descriptions that were being copied and pasted in had something called a non breaking space (ASCII character 160). This is wreaking havoc on a system that is trying to consume our data. From a MIF export perspective, probably best to strip all the non printable characters other than newline, carriage return and tab (that I can think of).
Unfortunately we went live on our 75 upgrade this past weekend thinking that this was only a minor issue that we could address post roll. Our users extensively copy and paste from documents and emails into the long description so now we are scrambling to correct the issues this is causing.
As always lately, IBM has been less than helpful. After being told Monday the development had a way to turn off rich text, yesterday I received an email indicating that maybe that was not exactly accurate. I will post updates on this
-Chris H
-----Original Message-----
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of ewald caspari 2
Sent: Wednesday, November 21, 2012 4:01 AM
To: Maximo Group
Subject: Re: [MAXIMO List] Long description dialog
yes,we will do this if disabling the dialog is not enough. Or perhaps we will strip the tags at saving, it's not decided yet what we will do.
Ewald
------------------------------
Have you considered using a processing class or and XML transformation to remove the tags from the rich text data and push them as basic text?
Chris.
Processing Invalid XML Data Through The Integration Framework
AnamitraBhattacharyya 100000B6YW | June 12 | Tags: mea mif validatexmltext xml base64 binarytext | Comments (0) | Visits (591)
inShare2Ratings 1 Integration framework uses XML messages to publish and consume data from and to Maximo. However there are a range of characters that are considered invalid for an XML document. The Maximo Mbo framework would allow such characters to be entered and saved into Maximo. Problem starts however when one tries to export that data through the Integration Framework.
For a list of allowed characters in XML 1.0 please refer to http://www.w3.org/TR/2000/REC-xml-20001006#charsets.
Most common way of introducing these characters is by copying some text from some word processing software like MS Word/ MS Power Point and pasting it on a text field [say description] or a text area [say long description] in the Maximo Application UI. These [xml invalid] characters might just be copied inadvertently and has no significance to the actual text content. On the other hand its entirely possible that these caharacters serve a purpose and conveys some meaning to the text content. In the former case we need to get rid of the characters and in the latter we would need to retain the characters. Fortunately the Integration framework can be configured to handle both the cases. Lets look at each one of them separately.
Lets take the case where the xml invalid characters [mostly control characters] got copied over inadvertently and the user tries to save the record. In this case there are 2 possibilities:
One [or more] Publish channel(s) associated with the Mbo save event [Add/Update/Delete] gets invoked [assuming the event is enabled for the channel]. In this case the channel would invoke the Mbo serialization routine [as per the Object structure defined for this channel] real-time.
No Publish channel is associated or the listener is disabled for the associated publish channel. In this case the record [mbo] gets saved - as mentioned earlier Mbo's do not complain on XML invalid characters and nor should they do so. At some point of time an admin person or an end user or a peer software might want to export/query the record using the MIF channels or XML/REST query services/apis. This in turn would invoke the Mbo serialization routine [as per the Object structure defined for this channel]. The only difference from #1 is - this one obviously is not real time - ie its happening [long] after the Mbo save has been done - and potentially is triggered by a user or a software that has no clue that an invalid XML data is lurking inside the Mbo.
Now as we have discussed earlier - most XML parsers do-not catch these XML invalid characters while creating the XML. So the only place to do this check is at the serialization [Mbo->XML conversion] time. There is a property defined just to control this - mxe.int.validatexmltext. By default its set to 1 [ie true] which implies the serialization process will validate any ALN data [which includes all other variations of ALN like UPPER]. Simply put - this will instruct the serializer to sniff out the invalid characters and throw an error. However the error would only indicate which Mbo attribute value has the XML invalid characters - and sniffing that bad character out [to "clean" the field value] is a manual/offline process which might prove to be tedious. Also there is some cost involved in parsing every ALN data for invalid characters. The cost becomes more pronounced when we are talking REST/XML queries which tends to be more real-time as opposed to an offline export. If for some implementation you are confident to not have such XML invalid characters - you might consider turning the check off by setting the property mxe.int.validatexmltext value to 0. Be aware that turning the property off would potentially result in generating invalid XML [in case the Mbo data contains XML invalid characters] which might not be detected till it reaches the External system.
Now lets look at the case when we are interested in keeping those characters - all it takes is just to flip a property value. The property name is mxe.int.binarytext. Setting the property value to 1 will instruct the serializer routine to
detect if there are XML invalid characters in the Mbo data.
If yes on step 1 - base64 encode the text data which converts the value to XML acceptable characters.
Write the converted value [base64 encoded string] to the XML.
Mark the XML element with a flag binarytext="true". A sample XML element will look like this - <DESCRIPTION binarytext="true">abcdefg</DESCRIPTION>.
So as we see here - the Mbo attribute value having the invalid XML characters is converted to a base64 encoded text which will always be XML compatible [by virtue of it being base64 encoded]. A simple base64 decoding is good enough to get the original value back. The onus however lies on the receiving end which should look for the XML attribute "binarytext" [for every element] and retrieve the original value by running a base64 decode routine on the XML element value.
The MIF de-serialization [inbound processing] process is equipped to handle this "binarytext" out of the box. So Maximo/Tpae would be able to handle production and consumption of this kind of XML without any custom code. For example Migration manager would heavily benefit from this - as both the XML generation and XML consumption is done using the integration framework. However other systems will not be as smooth in handling these kind of XML data - and they need to be customized to handle this situation [ie process the XML element value based on the "binarytext" flag per XML element].
Important thing to note here is - to have the "binarytext" feature enabled we need to have the "validatexmltext" feature turned on. Also the "binarytext" feature is only standard from the Maximo 7.5 releases. Prior to 7.5 release - the "binarytext" feature was only available programmatically such that only internal components would be able to access that feature.
Rgds Ian
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Hanna, Christopher CTR
Sent: 21 November 2012 13:11
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Long description dialog
If you go the route of stripping the tags, be aware that the rich text editors also allow other non-printable ASCII characters as well. We discovered that some of the long descriptions that were being copied and pasted in had something called a non breaking space (ASCII character 160). This is wreaking havoc on a system that is trying to consume our data. From a MIF export perspective, probably best to strip all the non printable characters other than newline, carriage return and tab (that I can think of).
Unfortunately we went live on our 75 upgrade this past weekend thinking that this was only a minor issue that we could address post roll. Our users extensively copy and paste from documents and emails into the long description so now we are scrambling to correct the issues this is causing.
As always lately, IBM has been less than helpful. After being told Monday the development had a way to turn off rich text, yesterday I received an email indicating that maybe that was not exactly accurate. I will post updates on this
-Chris H
-----Original Message-----
From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of ewald caspari 2
Sent: Wednesday, November 21, 2012 4:01 AM
To: Maximo Group
Subject: Re: [MAXIMO List] Long description dialog
yes,we will do this if disabling the dialog is not enough. Or perhaps we will strip the tags at saving, it's not decided yet what we will do.
Ewald
------------------------------
Have you considered using a processing class or and XML transformation to remove the tags from the rich text data and push them as basic text?
Chris.
GDF SUEZ E&P UK Ltd (Company Number 3386464), registered in England and Wales with a registered office address at: 40 Holborn Viaduct, London, EC1N 2PB.
**************************************************************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
**************************************************************************************************************