pxOutcomeTime in Email Impressions Getting set to 01/01/1970 in the Interaction History

General
, , ,
1

Dear All,

I wanted to bring to your attention an observation we’ve made recently regarding the pxOutcomeTime property in our Fact table for Email impressions. We’ve noticed that it’s being set to the default Java date, 01/01/1970.

This behavior seems to be occurring randomly, affecting only certain impressions. Some impressions are being stored in our IH with the correct pxOutcomeTime, while others are encountering this issue.

Best regards,

Mahesh

2

Hi @Mahesh_Sawant,

There are a few potential reasons why the pxOutcomeTime property is being set to the default Java date, 01/01/1970, in the PEGA CDH Fact table for Email impressions:

  • The pxOutcomeTime property is not being set correctly in the source system.

  • There is a data transformation issue in the PEGA CDH pipeline that is causing the pxOutcomeTime property to be set to the default Java date.

  • The data is being corrupted somewhere between system ingestion into the IH and the time the data is pulled from the CDM.

To troubleshoot this issue, you should:

  1. Verify that the pxOutcomeTime property is being set correctly in the source system.

check for the flow in which the update has been done. If the flow is present for updating pxOutcomeTime, check if that flow is getting triggered.

  1. Inspect the data transformation rules in the PEGA CDH pipeline to ensure that they are not causing the pxOutcomeTime property to be set to the default Java date.

  2. Review the data ingestion process and data pipelines to identify any potential issues that could be causing the corruption of the data.

Once you have identified the root cause of the issue, you can take steps to correct it and ensure that the pxOutcomeTime property is being set correctly in the PEGA CDH Fact table for Email impressions.

Hope it helps

Thanks

Megha

3

@Mahesh_Sawant INC-B11691 (Email Impression Capture Not Consistent) was closed by our support team as you did not respond. They provided you with clear steps on placing the loggers and executing the scenario.

If the issue is resolved, can you please provide the solution here, or mark @Megha007 's reply with accepted solution if this helped correct your problem?

4

Support ticket was resolved with the below details:

Resolution notes: Worked with the client to update the pxOutcomeTime in the captureinteraction strategy itself as we see some issue while doing the same in extension strategy, a major consideration to keep in mind while CDH version upgrade in future is to observe if there is a change in CaptureInteraction strategy and adopt those changes.

As client has customized this strategy in their layer, the future changes in the strategy will be ignored because of local customization.

Before giving this suggestion, we tried to do the same change in the captureInteractionExt strategy but due to conditional operator(?:slight_smile: returning an error that both the return types(date time and pxOutcomeTime) are different, so went with this approach.

How can this type of assistance be prevented in the future :

handling this as part of OOTB captureinteraction strategy to configure pxOutcomeTime as part of 24.2 release