IBM Connections - side-by-side migration of Activities fails - table mismatch - OPNACT . OA_NODE

I had a few migration from 5.5 to 6.0 within the last weeks and I came accross the following error every time:

11/02/17 10:32:39.347 CET] Processing table -{ OA_NODE->OA_NODE }- 
11/02/17 10:32:39.347 CET] SELECT * FROM "ACTIVITIES"."OA_NODE" 
[11/02/17 10:32:39.722 CET] Transferring table --{ ACTIVITIES.OA_NODE} -- to table --{ACTIVITIES.OA_NODE }--
[11/02/17 10:32:39.957 CET] ERROR: Error validating data. The number of values is not equal to the number of columns in the destination table OA_NODE
 [11/02/17 10:32:39.957 CET] ERROR: The number of values is 38 while the number of columns is 37 
 [11/02/17 10:32:39.957 CET] error.executing.transfer com.ibm.wps.config.DatabaseTransferException: Column number mismatch

I was able to solve this error by just adding the missing table in the target database (DB2) with the following command:

  ALTER TABLE ACTIVITIES.OA_NODE ADD COLUMN OWNERMEMBERUUID CHAR(36) NULL;
ALTER TABLE ACTIVITIES.OA_NODE ALTER COLUMN OWNERMEMBERUUID DROP DEFAULT;
ALTER TABLE ACTIVITIES.OA_NODE ALTER COLUMN OWNERMEMBERUUID DROP NOT NULL;
ALTER TABLE ACTIVITIES.OA_NODE ALTER COLUMN OWNERMEMBERUUID SET DATA TYPE CHAR(36);
CALL SYSPROC.ADMIN_CMD( 'REORG TABLE ACTIVITIES.OA_NODE' ); 

I opened a PMR for this because I wanted to know what was causing this issue:
The table itself was no longer used in 5.5 which is why it was removed from the 5.5 createDB.sql and the upgrade-50CR1-55.sql script at some point.
But all "old" 5.0 envoirnments that were migrated to 5.5 still have this obsolete table.

To solve this problem you may also just delete the column and its index from the OA_node table in the source db. Thanks to David McCarthy from ICS Support IRL for this hint.


Regards,
Jan

IBM Verse On Premise - problems with integration of IBM Connections Files

I just setup an testing envoirnment for Verse On Premise.
To get the full features I also tried to integrate IBM Connections which enables you to use business cards, photos & also let you use your Connections files for your mail correspondence.


After performing all required steps based on the official documentation it seems to be working fine:

 But when I tried to attach a file from IBM Connections I got the error message "service unavailable".
Checking the IHS access logs the following error is printed:

 [24/Feb/2017:10:00:55 +0100] "OPTIONS /files/basic/api/people/feed?self=true&xhr=1&sq=1 HTTP/1.1" 403 162
[24/Feb/2017:10:00:55 +0100] "OPTIONS /profiles/atom/profile.do?mcode=5b65e3542ff4be446f8cd1db987ac3df HTTP/1.1" 403 162

I tried to find a cause why the access should be "forbidden" but I couldn't find any indicator in theSysOut logs and also accessing the referenced URLs directly was working fine - so I asked Google for a solution.

Luckily I found this article from Roberto Boccadoro. He also had the same error and one of his buddies found a solution:
Instead of using the provided IHS configuration of IBM add the following lines to your configuration in the VirtualHost section:

RewriteEngine on

# Minor change to adjust for Cloud vs On-Premises API variation of parameter name
RewriteCond %{REQUEST_METHOD} PUT
RewriteCond %{QUERY_STRING} ^(.*)uid=(.*)
RewriteRule ^/profiles/photo.do /profiles/photo.do?%1userid=%2 [L]

# Added necessary CORS headers when Origin header present
Header unset Access-Control-Allow-Origin
SetEnvIf Origin "^https://(vop_server_hostname\.)?(domain_name)$" origin_is=$0
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is
Header always set Access-Control-Allow-Credentials "true" env=origin_is
Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, slug" env=origin_is
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" env=origin_is

Header always set Access-Control-Max-Age "1000" env=origin_is
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" env=origin_is
# Header always set Access-Control-Allow-Headers "X-Requested-With, Content-Type, Origin, Authorization, Accept, Client-Security-Token, Accept-Encoding, slug" env=origin_is
Header always set Access-Control-Allow-Headers "X-Requested-With, Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma, slug, X-Update-Nonce" env=origin_is
Header always set Access-Control-Expose-Headers "Content-Disposition, Content-Encoding, Content-Length, Date, Transfer-Encoding, Vary, ETag, Set-Cookie, Location, Connection, X-UA-Compatible, X-LConn-Auth, X-LConn-UserId" env=origin_is

# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* - [R=200,L]

# Remove the Origin header if it exists for other requests (POST, GET, DELETE, PUT). Causes problems with Connections returning 403 response.
RequestHeader unset Origin env=origin_is

....I would have never expected a RewriteRule to be the workaround for a 403 error but now I finally got my envoirnment running 😌