Clarity

We recently upgraded our Test system from 13.0 to 14.2. Between when we froze our test environment and completed the upgrade (almost a month, but thats another matter), we added some portlets/pages to our Train and Prod systems that are still on 13.0. I'm trying to XOG out those portlets from Prod/Train, and XOG them in to Test, but I'm getting the error below. I can run the XOG in either 13.0 system without any issues, and I've run the XML through some parsers and don't get any warnings. Anyone else having issues XOGging between versions? I tried changing the version number in the header but that made no difference. Attached is the XML I get from the 13 systems I've tried with a few different portlets but most have custom objects/attributes, I think this one has only standard fields from the base install and the PMO accelerator pack (Status Reports)

<?xml version="1.0" encoding="UTF-16"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
    <XOGOutput xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/status.xsd">
      <Status elapsedTime="0.0 seconds" state="FAILURE"/>
      <Statistics failureRecords="0" insertedRecords="0" totalNumberOfRecords="0" updatedRecords="0"/>
      <ErrorInformation>
        <Severity>FATAL</Severity>
        <Description>Exception while processing client request</Description>
        <Exception type="com.niku.xog.XOGException">Input document contains Illegal HTML character for object contentPack</Exception>
      </ErrorInformation>
    </XOGOutput>
  </soapenv:Body>
</soapenv:Envelope>

Hi Lino,

try removing the NLS language settings where language code !=en.

you can use XSLT for this, if you need an example, i can send to you.

cheers,

Federico

If everything else fails try a different  version of the XOG client.

Bingo, this did the trick atleast on the file I attached, will test with others tomorrow but I imagine it will resolve for those as well. I also updated my Xog_Bridge client to the latest version (was a few behind).

Hi Elias,

Can you brief Exactly what steps you took to resolve the issue?

Regards

Gyan

I believe in the end I used the standard CA XOG client to load the file back in. Since then we rolled back our Test, refreshed the DB from prod, and rerun the upgrade so I havent had the issue again

Hi fpnea,

I am facing the same issue - XOG read a protlet from 13.1 version and trying to XOG write in 14.2 version and the error pops out.

Tried replacing all the NLS language tag with XSLT and issue still there.

Could you please help me.

Regards,

Freddy

navzjoshi00 - could you please help me in this.

Does the input file open OK in a browser?

Did you try removing the NLS bit from the input XML where language is not equal to "en" ?

NJ

Removing the NLS is a sikmple and quick way to remove the nonascii character en masse from the xml file.

However, that does not solve the problem if it is caused by a non ascii character or HTLM escape code or XM reserved character in the name, code, ID of and item.

Once you have done that opening the file will in a browser will check some of those listed above.

Agree

NJ

It can also be a typo, but not if it is the direct output from XOG read.

Hi Everyone,

Few Updates :-

One of my Portlet was giving same issue. I tried to remove the NLS language settings where language code !=en using XSLT.

I was able to XOG in after that.

But when I try to XOG Out the same Portlet and changed the portlet ID and XOG back in, It again Fails.

We are in multiple language support and doubt if everytime changing the NLS might effect other Users.

Is there any way to find out the root cause for the same ?

Regards

Gyandeo Shukla

When you XOG in the portlet (using the file you have removed all the non-EN NLS information from), make sure that you have deleted the information from the target application system (eg the portlet and the query and and portlet-specific lookups).)

Then XOG out the portlet again - check the NLS - the data for every non-EN language should be the same as the EN language.

(I am GUESSING that when you have XOG-ed in the "clean" portlet, it has not replaced any of the non-EN NLS information, which is where your "special" characters are, so they then included the next time you XOG out the portlet)

Or you could just use your "clean" XOG file to create your "new" portlet?

Hi David,

This is the step I followed as per your suggestion:-

1. Cleaned out all NLS data for non-EN language

2. Deleted the existing Portlets and Query from Application.

3. Changed the PotletID and Query ID in XML before XOgging in.

4. Xogged the new file in environment.

Result, I was able to XOG in successfully.

Now Further steps was :-

1. Xogged out the Portlet (New Portlet Xogged in above).

2. Checked, It had different NLS in the file with Values which system itself creates.

3. Changed the Portlet and Query ID again.

3. Tried to XOG in the same.

Result It again Failed with same issue.

I am opening a CA Case for this.

Also I have one quick question :-

When I am using XOG Client 14.2, the XML File that is created becomes messy (not formatted one) as it is when we xog out from 13.2. Have you ever come across this?

Regards

Gyandeo

OK, perhaps you need to supply your own (clean) NLS in the application then (rather than the system default), I usually copy/paste the EN information into the non-EN fields because I usually have changed the EN label from the system generated one anyway. You could also do that in the XML files (instead of removing the non-EN, copy&paste the EN text into the other non-EN fields - this can become a tedious copy&paste exercise in any text-editor)

(and sorry, no help on the "messy" output)

The messy output is a know feature (as designed)

I use XML View plus

See

https://communities.ca.com/message/241698893#241698893