Update on the Touchpoint workaround (Updated)

Last Update:

Author: Christoph Stoettner
Read in about 3 min · 428 words

Fountain pen and a notebook

Photo by Aaron Burden | Unsplash

Some weeks ago I wrote about an workaround to prevent TDI from deleting the touchpoint status in HCL Connections .

During some research on TDI I found Mapping fields manually in the HCL Connections documentations. This document describes how to add additional fields to the TDI synchronisation. On point 11 I found something new for me. You can add additional fields and then add the content with an Javascript function for example.

Then TDI does not make an LDAP call to get the attribute from there, instead it uses the function. So an additional workaround for the Touchpoint state problem is to add the five fields defined in conf/LotusConnections-conf/tdi-profiles-config.xml to map_dbrepos_from_source.properties and set it to null. Setting attributes to null does not delete the content in the database, but just does nothing (no update, no creation).

Example: add this to the end of your map_dbrepos_from_source.properties


That’s way easier than commenting out the field definitions and if you ever need to set the fields, you can just add the attribute or function to map_dbrepos_from_source.properties.

## Update 10.05.2021

I’m really sorry, but this workaround seems not to work as expected.

So the best way, that the touchpointState is not overwritten on each TDI run is to comment out the fields in tdisol/conf/LotusConnections-config/profiles-types.xml and tdisol/conf/LotusConnections-config/TDI-LotusConnections-config.xml!

Update 17.08.2022

With Connections 7.0 CFix.70.2206 the issue is still not fixed! So each time when sync_all_dns.sh is running and a user has touchpointState set in EMPINST.PROFILE_EXTENSIONS it gets deleted. I have no environment, where the touchpointState is written or read from LDAP.

As I wrote in the original article you can uncomment the lines in conf/LotusConnections-config/tdi-profiles-config.xml, but then you need to remove the field definition in conf/LotusConnections-config/profiles-types.xml too.

From my point of view the fastest fix for this is to remove the sourceKey from tdi-profiles-config.xml:

Original definition:

<simpleAttribute extensionId="recommendedTags" length="256" sourceKey="recommendedTags" />
<simpleAttribute extensionId="departmentKey" length="256" sourceKey="departmentKey" />
<simpleAttribute extensionId="privacyAndGuidelines" length="256" sourceKey="privacyAndGuidelines" />
<simpleAttribute extensionId="touchpointState" length="256" sourceKey="touchpointState" />
<richtextAttribute extensionId="touchpointSession" maxBytes="1000000" sourceKey="touchpointSession" />

Change to:

        These extension attributes are required by the 'Touchpoint' component
<simpleAttribute extensionId="recommendedTags" length="256" />
<simpleAttribute extensionId="departmentKey" length="256" />
<simpleAttribute extensionId="privacyAndGuidelines" length="256" />
<simpleAttribute extensionId="touchpointState" length="256" />
<richtextAttribute extensionId="touchpointSession" maxBytes="1000000" />

This allows the field in profiles, but does not read the state from LDAP. As I have node of the five attributes in LDAP, I removed the sourceKey from all attribute definitions.

Add a comment
There was an error sending your comment, please try again.
Thank you!
Your comment has been submitted and will be published once it has been approved.

Your email address will not be published. Required fields are marked with *

Suggested Reading
Aaron Burden: Fountain pen and a notebook

HCL included some additional apps with HCL Connections 6.5CR1. One of them is Touchpoint, which can be used to present users the “Terms and Conditions” (or Privacy and Guidelines) of the environment and some help creating their profile, network and become member of their first communities.

Touchpoint writes some profile extension entries in the PEOPLEDB database in the table PROFILE_EXTENSIONS, most important:

Last Update:
Read in about 3 min
Card image cap

Last week I played around with the HCL Connections documentation to backup Elasticsearch in the article Backup Elasticsearch Indices in Component Pack .

In the end I found that I couldn’t get the snapshot restored and that I have to run a command outside of my Kubernetes cluster to get a snapshot on a daily basis. That’s not what I want.

Created: Read in about 4 min
Card image cap

During a migration from Cognos Metrics to Elasticsearch Metrics, I had some issues with the index. So I wanted to create a backup of the already migrated data and start over from scratch.

The official documentation has an article on the topic: Backing up and restoring data for Elasticsearch-based components , but I had to slightly adjust the commands to get a successful snapshot.

Last Update:
Read in about 6 min