IBM SBT: Updating a subcommunity breaks subcommunity relation? - ibm-sbt

Question

I have implemented creation of subcommunities using IBM SBT 1.0.2.20140527-1807 against IC 4.5 (thanks for heavy API changes from 1.0.1 :-/ ) and want to update a freshly created subcommunity with a nice "content" containing some HTML with links to some content inside this community. Thus I must first create the subcommunity and afterwards update the "content" attribute, because I need some data not yet present before successful creation.
The way I do this is basically as follows:
(1) Create subcommunity [proven successful, and it IS a subcommunity now]
(2) Fetch the new subcommunity using CommunityService.getCommunity(communityUuid) [proven successful]
(3) execute community.setContent(string) [no errors]
(4) execute CommunityService.updateCommunity(community) [no errors]
The REST request created and sent for CREATE is:
POST /communities/service/atom/community/subcommunities?communityUuid=8ea4ff45-ef58-4c9b-b131-def2d3e233f7
The XML data sent is:
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app" xmlns:snx="http://www.ibm.com/xmlns/prod/sn">
<title type="text">mytitle</title>
<content type="html">mycontent</content>
<category term="community" scheme="http://www.ibm.com/xmlns/prod/sn/type"></category>
<category term="mytag"></category>
<snx:communityType xmlns:snx="http://www.ibm.com/xmlns/prod/sn">private</snx:communityType>
</entry>
The REST request created and sent for UPDATE is:
PUT /communities/service/atom/community/instance?communityUuid=ae63bedf-98f2-45d4-ad6a-4dfd1f3a58d7
The XML data sent is:
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app" xmlns:snx="http://www.ibm.com/xmlns/prod/sn">
<title type="text">mytitle</title>
<content type="html">mycontent</content>
<category term="community" scheme="http://www.ibm.com/xmlns/prod/sn/type"></category>
<category term="mytag"></category>
<snx:communityType xmlns:snx="http://www.ibm.com/xmlns/prod/sn">private</snx:communityType>
<snx:communityUuid xmlns:snx="http://www.ibm.com/xmlns/prod/sn">ae63bedf-98f2-45d4-ad6a-4dfd1f3a58d7</snx:communityUuid>
<id>http://communities.ibm.com:2006/service/atom/community/instance?communityUuid=ae63bedf-98f2-45d4-ad6a-4dfd1f3a58d7</id>
</entry>
Afterwards the content is indeed updated -- but the community is not a subcommunity any more, but a regular top level community.
Why is that?
What can I do about it?

Answer 1

For the impatient: I have found the root cause, and in some circumstances this offers the possibility for a workaround.
The root cause is that the Community representation in IBM SBT SDK (Java) currently (as of July 2014) does not offer a "parent community URL" element.
http://www-10.lotus.com/ldd/appdevwiki.nsf/xpDocViewer.xsp?lookupName=IBM+Connections+4.5+API+Documentation#action=openDocument&res_title=Community_entry_content_ic45&content=pdcontent says that a community XML representation has a <link rel="http://www.ibm.com/xmlns/prod/sn/parentcommunity" type="application/atom+xml" href="..." /> element (where href is the atom/instance URL, not the "community URL" with html/communityview) if it represents a subcommunity, which is ignored on PUT/POST -- but:
THIS IS NOT TRUE:
In fact this element is REQUIRED on PUT to keep a community's "sub community" nature on change. And worse: If it is broken, it cannot be "repaired": Because of other limitations for subcommunities, an existing community cannot be changed to become a subcommunity of another top level community. Subcommunities can only be CREATED (and kept, of course).
What I have done to work around that pitfall is to subclass Community and some other classes to extend the XML marshal/unmarshal mechanisms in SBT SDK to cope with parent community URLs. If you know what you're doing everything is fine, but if you want generic code which simply does not break subcommunities, you must also READ ALL COMMUNITIES as if they may be subcommunities. If you don't, you won't see this information and write back the community as top level community.
Thus it is better to wait if you can :-(
I expect IBM to extend the implementation of Community and related classes by a parent community URL field. What I am curious about is how they will deal with the fact that the complete Atom feed URL is required, including the server address and the parent community UUID. I took the q&d way and changed the community URL as returned by parentCommunity.getCommunityUrl(), but this eventually does not take into account the various AUTH variants.

Answer 2

IBM SBT SDK 1.1.0 of Jul 17, 2014, seems to be out. At least it is available in Maven central.
This is the better answer of course but will require several code adjustments if you have built code on top of internal structures due to some internal refactorings.