Clarity

Hello Friends,

I've noticed a behaviour I cannot fully understand when trying to read a portlet throught XOG.

I'm attaching the xml files so (if you want to) you can take a look at them.

I attempted to read the portlet in two ways:

One way I tried was using the export option on portlet list. It created the xml write file with the portlet details. But when I want to call to this xml throught XOG I recevied an error message on the command promtp and I got disconnected from XOG.

Second attempt was using the content pack xml filtering only for the portlet I wanted to extract. This is not working as expected since it is reading all the information from the content pack no matter if I set a filter. So when I wanted to xog it in the destiny environment ended with error XOG-3250: Portlet record has not been inserted. I once hit this same error and was because the xml was huge. So That time I resolved the problem by manually cleaning the writing xml file so only the portlet I wanted to transfer was in it. I don't find this very useful. Every time I need to move a portlet I need to clean all the xml file, I don't think it is working as it should.

I opened a ticket with support and the engineer suggested to increase the -Xmx parameter. He suggested to double my current value and to try again to xog in the xml, and if it fails again, double it once more... and so on.

I don't think this workaround is advisable, because when I want to move a portlet from one environment to another  I mean to move it from DEV to PROD, for instance, and if I'm taking all the content pack  might be moving configuration which is in DEV to PROD and that might not be ready to be taken to PROD.

I appreciate if anyone could let me know if they have hit this same behaviour, if someone apply this increment that CA support has suggested and if it's OK.

Thanks a lot!!

Flo

Attachments Descriptions:

osde_nuevo56_W.xml is the write file created through XOG

osde_nuevo56_R.xml is the read file

osde_nuevo_56_OUT.xml is the output with error XOG-3250

error from cmd.txt is the error I get in command prompt when trying to xog in the xml file created by the export option on the portlet list.

Message was edited by: Florencia Goya

This is the "read a portlet" XML that I use with no problems, this might differ from your "content-pack read" because of the no_dependencies arg?

<?xml version="1.0" encoding="UTF-8"?>

<NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_read.xsd">

  <Header version="13.0" action="read" objectType="contentPack" externalSource="NIKU">

    <!-- you change the order by simply swap 1 and 2 number in the name attribute -->

    <args name="order_by_1" value="code"/>

    <args name="no_dependencies" value="true"/>

</Header>

  <PortletQuery>

    <Filter name="code" criteria="EQUALS">xxxxxxxxxxxxxxxxx</Filter>

  </PortletQuery>

</NikuDataBus>

Oh! I understand! So it brings only the portlet, just the portlet.

I will give it a try and will let you know my results.

Thanks a lot Dave!

Regards

Flo

Should bring back the portlet, the query and any lookups that are used - but thats it.

(there were some odd bugs in earlier versions when the portlet's query contained a link to an object (eg project) that it then brought back TONS of extra junk)

If your command line looks like that there something wrong and you went straight to the interface and are not using the XOG command line client.

There was discussion about that when the v13.3 came and the same happened Consequently some people used 13.2 XOG client, but eventually it turned out v13.3 client works as well.

If I recall correctly you had to modify the input file a little. Search the discussions in this community..

There are of course the third party tools where you do not have that problem.

Secondly your input file is 27 megs unzipped. Just forget it. It is not likely to to be written at allso never mind the error.

A large file something like 5 -6 megs. You should be able to split your file into smaller pieces (if you want to use that file)

With portlets  there  is a simple way to get just to bare bones portlet : Go to the portlet list, select your potlet and click export.

You would have to XOG the lokups, queries, maybe objects etc. before you can xog in the bare bones portlet.

I did a little test in in v13.3 with your input file and I still think that it is your environment and maybe not having supprted 32 bit jre installed.

My write.properties file is

# --- server host name you want to test against

#VM#

servername=w2008

username=kinnunenad

password=<password>

portnumber=80

sslenabled=false

sslenabled=false

input=../Input/osde_nuevo56_W.xml

output=../Output/osde_nuevo_out.xml

in the command prompt I launch write.bat in the ..\XOG\bin folder

Time

call XOG.bat -propertyfile write.properties

Time

The Time commands are there just to help to know how long it takes.

The command window is when i run you input

As you can see it uses the XOG command line client and does not go into the interface.

The output is

Which is different form from yours as it is from the XOG command line client.

In my case it does not get very farm because there is Incorrect syntax..

My first guess for that would have been ANSI encoding of the file and non ascii characters, but your file is UTF-8 encoded so that is not the problem.

Second guess is the your file is not for v13.3  as it says  version="13.2.0.472" in the file.

There may have been a change in syntax between those version.

You're getting a different error due to an issue that I think should be resolved if you use 13.3.0.2 or higher.  It was a problem that caused line-end markers in the XML to be removed putting the SQL all onto one line; which in many cases would result in the lines running into eachother without a break or whitespace giving an apparent syntax error.

Often it reports 'FROM not found where expected' due to the way queries are commonly constructed, but in your case the new line appears immediately after the first SELECT and causes the first column of the query on the next line to get merged together.  It's the same error and cause though.

Reference: http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec614115.aspx

Thanks Nick, if you say so.

I was just trying to illustrate that when I run the XOG command line client it looks different from what Flo posts and does not give that error at that point.

It should be easy to get rid of my error either by installing the patch or doing the XOGing to v13.2.

What might be the problem with Flo's set up? As far as I can make it it looks like a standard content pack portlet.

It is a standard content pack portlet definition, there isn't anything wrong with the content per se.  I believe Flo received a response via her support ticket on the subject (at least I'm aware of the discussion the support engineer has had about it internally and the solutions they were providing), which coincides with the advice David has given regarding the use of the no_dependencies argument to avoid having a XOG file that contains enough information to exceed the default -Xmx settings of the xog.bat, so I have nothing further to add to his reply really.

Hi Nick! Support advice was to edit the xog.bat to increase the -Xmx parameter. They suggested to double my current value and to try writing again, and if it did not solve my issue, to continue doubling the value. I did not felt very convinced of the solution the provided so this is why I opened this post in the community.

I was expecting to receive an analysis more like the one David gave me, as adding the 'no_dependencies' argument.

Anyway, I'm still not succeed to xog the portlet.

Thanks!

Flo

The memory doubling of the -Xmx parameter is recommended on the basis that the client configuration is much lower than the server configuration, so what may be acceptable for the server to process can sometimes not even get that far due to the client configuration being too restrictive.

There are situations where this is an acceptable way to overcome a problem; particularly with large XOG files and there isn't a very proportional comparison between the -Xmx parameter and the size of the XOG file either.  In your specific case though, you only really wanted the portlet and the dependencies brought out other content belonging to some addins as well, and for that other options are probably more suitable.

The issue where some non-linebreak whitespace is required at the end of each line of the SQL only applies to Clarity 13.3.0 until 13.3.0 patch 2, and that is only to workaround the specific problem being reported in urmas' post.  Versions before and after this would not need to use or benefit from that workaround.

Perfect! Many thanks for your clarification Nick! I will keep on trying with my xml file with the 'no_dependencies' argument.

Hi! David! I tried your suggestion and was able to extract a smaller xml file, so I guess I am now reading only the portlet I requested.

Unfortunately it did not resolve my issue, so I went through with Nick suggestion and manually add a space at the end of every nsql line.

It did not solve my issue as well.

I still get error :

<Severity>FATAL</Severity>

        <Description>XOG-3250: Portlet record has not been inserted. com.niku.xql2.XQLVisitorException&#xd;

  at com.niku.xql2.handlers.ThrowHandler.postProcess(ThrowHandler.java:25)&#xd;

  at com.niku.xql2.XQLVisitor.postProcess(XQLVisitor.java:1355)&#xd;

  at com.niku.union.xml.dom.DOMWalker.postProcess(DOMWalker.java:210)&#xd;

  at com.niku.union.xml.dom.DOMWalker.traverseIntern(DOMWalker.java:94)&#xd;

  at com.niku.union.xml.dom.DOMWalker.traverseIntern(DOMWalker.java:92)&#xd;

  at com.niku.union.xml.dom.DOMWalker.traverse(DOMWalker.java:51)&#xd;

  at com.niku.xql2.handlers.LoopHandler.processObject(LoopHandler.java:161)&#xd;

  at com.niku.xql2.handlers.LoopHandler.preProcess(LoopHandler.java:91)&#xd;

  at com.niku.xql2.XQLVisitor.preProcess(XQLVisitor.java:1342)&#xd;

  at com.niku.union.xml.dom.DOMWalker.preProcess(DOMWalker.java:194)&#xd;

I was optimistic at first because when I first run my edited writing xml the output showed an error regarding a missing field. We then created it and went through the write xml once again, but then, returned to the first error, which I pasted above.

I also tried to write the same portlet back into the environment from where I read it, but it gave the same error.

Clarity version is 13.2.0.472 

Thanks to all for your suggestions

Are you able to share the revised versions of both of those files (the smaller XOG output, and the full response you received from attempt to XOG write)?  The part of the error showing is a part of an error that can be common to a variety of causes.  If there are no further details in the response of your XOG write, then further error details may have been placed into your app-ca.log file instead.

Also for reference, this is the area in the documentation that refers to the options available for performing a smaller content pack export in Clarity 13.2 (requires login to view): https://support.ca.com/cadocs/7/CA%20Clarity%20PPM%2013%202%2000%20%20On%20Premise%20-%20Restricted%20Content%20-ENU/Bookshelf_Files/HTML/xog/index.htm?toc.htm?1387017.html#o1386850

Aside from the no_dependencies argument, there is another for limiting the output as well called singleContentType, or you can try to use the UI version of the Export option on the portlets page.

Problems that may occur when trying to XOG this into another environment can include things, like for example, there being references to lookups in the portlet filter for a lookup definition that exists in the source environment but not in the destination, so it would need to be imported/created first before adding a portlet.

I'm not finding the option to attach files into the reply...

I think that is because we are using the 'quick reply' editing Window.  When you're viewing the URL of the original thread and you go to reply, you should see an option for Use Advanced Editor (in the top-right corner of the editing window/toolbar) - and I believe that one will allow you to include links to files.

Hi! Here are the files:

osde_nuevo56.W1.xml is write file.

osde_nuevo56_OUT1.xml is the response file created after trying to xog in in the destination environment.

Hi all!!

I really don't know what to say or how to explain this, but I suddenly was able to move the portlet from one env to another without any issue.

I'm attaching my 3 final files in case anyone feels curious and want to give them a look, but I certainly did not make any modifications.

I did one try which consisted in creating the query in which the portlet was based manually. Then I moved the portlet. It threw an error related to the syntax on the nsql query in the response file. I corrected and then was able to succesfully xog in the portlet.

Next step: I deleted both the query and the porltet. And try to xog the portlet through the xml file without having the query created on the destination environment. Just like I did in the beginning.

Results: I was successfully to read and to write the portlet with its query.

I wasn't totally convinced, so I tried all the steps once again using new xml files, and I was success once more. I really don't understand what happened but I do really appreciate the time you all took to share with me your thoughts.

I now need to success xoggin in the portlet into PROD environment. Wish me luck!

Thanks!!

Flo