Storage Extension | LocalThreadTransaction.getTransactionId() always returns null

Question

I am developing a simple Storage Extension for Tridion Docs. In the extension code I have a class that is using LocalThreadTransaction class from the namespace com.tridion.storage.services.LocalThreadTransaction the same way as SI4T class TridionBaseItemProcessor.

The issue is LocalThreadTransaction.getTransactionId() always returns as Null. Any idea what could be wrong with my code?

import com.tridion.storage.extension.models.RestRecord;
import com.tridion.storage.services.LocalThreadTransaction;
import org.slf4j.Logger;

public class SBXItemProcessor {

    public static void addSBXItem(int pubId, RestRecord.operation opr, Logger log)
    {
        log.info("Adding publication:" + pubId + ", for action: " + opr.toString());
        RestRecord record = new RestRecord(pubId, opr);
        SBXIndexProcessor.registerAction(LocalThreadTransaction.getTransactionId(), record);
    }
}

Update:

As answered here, I tried LocalThreadTransaction.get() inside a DAO but it returns null there as well.

Answer 1

Unfortunately, I did not find a solution to the issue as the issue resides in core libraries.

Currently, for SDL Docs, it is not possible indexing to the data-sources on CommitTransaction method as we do for SDL Sites because of the issue.

For a temporary solution, I start indexing the data to a temporary queue (Azure Servicebus in my case) from JPASearchPublicationDAO class and process this queue record after a few mins assuming the transaction is committed at SDL Docs end. For Ref: (https://github.com/SI4T/SI4T/blob/66b181d9cc5fe769359e17f3f31013a098da0a29/storage-extensions/src/main/java/com/tridion/storage/si4t/dao/JPASearchPageDAO.java#L66)

I know this is not perfect but it works for us because the publishing frequency in docs is quite low.

Few approaches, I would like to try in the future:

1. Since docs publishing is single-threaded, we could avoid the transaction id because there would always be one publishing transaction in processing. (NOTE: For a single publish in SDL Docs, it results in 4 sub-transactions in the storage layer. So the challenge will be to index the data only once and not 4 times)

2. In my case, I don't need to index too much data but only publicationId and the publish action so a storage extension seems an overkill. I will try to develop an event plugin (as configured in "Settings -> Write plug-in XML settings") where I catch the publish event and index the data.

Hope this helps.

Answer 2

We had a similar issue and fixed this issue using surrogate keys implemented Cumulative HF CD_11.1.0.19562

For the custom deployer storage extension you might need the following dependency jars.

• udp-common-config-legacy-11.1.0-1080.jar
• udp-common-util-11.1.0-1080.jar
• udp-core-11.1.0-1070.jar
• udp-data-legacy-transport-11.1.0-1019.jar
• udp-data-model-compatible-11.1.0-1019.jar
• udp-datalayer-11.1.0-1110.jar
• udp-storage-api-11.1.0-1020.jar

In our case, we did Tridion Docs 14SP2 published DXD binaries to the google cloud platform using SI4T based custom deployer storage extension, Tested against DXD 11.1 + CD_11.1.0.19562 Deployer-combined, It was working fine as expected.

I hope it helps.