HCI to Successfactors : Delta-Sync. How does it work?

[former_member207428]

We have read the 'Developer's Guide: Managing Integration Content', page 80 : Configuring Delta Sync Scenarios.

     You can configure SuccessFactors connector to fetch the modified or delta records instead of fetching all the records. This optimizes the polling mechanism. This is known as delta sync configuration.

• With this configuration, the system fetches all records from the beginning of time (1/1/19070, by default) in the first run. Only modified records are fetched in the subsequent runs.
• Note : If the payload from the SuccessFactors system has execution_timestamp as one of the fields, that time-stamp is used as the reference date for the subsequent delta sync polling cycles. The date specified in the Query is ignored.

As a test, we modified a record in SuccessFactors at 11:30:51 local time - which corresponds to 09:30:51.00Z, as HCI uses UTC time in the query - by updating address_information/housenumber from 4 to 5.

a) Let's see if we can detect the changes starting as of 09:29:00Z, our query contains :

     WHERE last_modified_on >= to_datetime('2016-05-23T09:29:00Z')

     Output file contains the modified record, the changes were detected, this is correct, as the changes were performed after 09:29:00Z.

<?xml version="1.0" encoding="UTF-8"?>

<queryCompoundEmployeeResponse>

                <CompoundEmployee>

                    <id>3030</id>

                    <person>

                               <country_of_birth>SGP</country_of_birth>

                               <created_by>AdminMA</created_by>

                               <created_on_timestamp>2016-05-20T12:47:05.000Z</created_on_timestamp>

                               <custom_long1>32</custom_long1>

                               <custom_string2>SSO</custom_string2>

                               <date_of_birth>1983-11-14</date_of_birth>

                               <last_modified_by>AdminMA</last_modified_by>

                               <last_modified_on>2016-05-20T12:47:05.000Z</last_modified_on>

                               <logon_user_id>129</logon_user_id>

                               <logon_user_is_active>true</logon_user_is_active>

                               <logon_user_name>129</logon_user_name>

                               <person_id>3030</person_id>

                               <person_id_external>129</person_id_external>

                               <place_of_birth>Singapore</place_of_birth>

                               …

                               <address_information>

                                               <address1>Rue des Arbres</address1>

                                               <address2>5</address2>

                                               <address_type>home</address_type>

                                               <city>Metz</city>

                                               <country>FRA</country>

                                               <created_by>AdminMA</created_by>

                                               <created_on_timestamp>2016-05-20T12:48:46.000Z</created_on_timestamp>

                                                               <end_date>9999-12-31</end_date>

                                                               <is_global_model_address>false</is_global_model_address>

                                                               <last_modified_by>AdminMA</last_modified_by>

                                                               <last_modified_on>2016-05-23T09:30:51.000Z</last_modified_on>

                                                               <start_date>2016-04-12</start_date>

                                                               <zip_code>1000</zip_code>

                               </address_information>

                               …

                    </person>

                    <execution_timestamp>2016-05-23T09:41:39.000Z</execution_timestamp>

                    <version_id>1602P0</version_id>

                </CompoundEmployee>

  </queryCompoundEmployeeResponse>

b) As we can see, execution_timestamp is updated to 2016-05-23T09:41:39.000Z.

     So, let's peform a delta-sync :

     WHERE last_modified_on > to_datetime('${deltasync.maxDateFromLastRun}')

     Output file contains again the modified record, the changes were detected.

     Now, according to the documentation :

     'If the payload from the SuccessFactors system has execution_timestamp as one of the fields, that time-stamp is used as the reference date for the subsequent delta sync polling cycles. The date specified in the Query is ignored',

     Since execution_timestamp '2016-05-23T09:41:39.000Z' is present, why is the data returned ?

c) What properties are taken into account to identify the polling and where are they stored?

     According to the documentation, The channel name is used as identifier in the delta sync configuration.

          A new name resets the existing delta sync configuration.

          Caution : Choose a unique channel name. Do not use names that were used in earlier delta sync configurations.

     I have performed some tests :

1. First test : two different sample projects, that use the same channel-name & same SuccessFactors query, deployed on the same tenant.

We performed a delta- sync, followed by a change in SuccessFactors.

Although project 1 performed a delta-sync to SuccessFactors, project 2 was also able to detect the change and returned the modified record.

     b. Second test : deploy the same project 1 to two different tenants (TST and PRD), but connect to the same SuccessFactors source system (PRD) and performed the same test in a) by modifying a record in SuccessFactors.

Projectname, channel names and delta-sync query are the same on both tenants.

We performed a delta- sync on the TST tenant, followed by a delta-sync on the PRD tenant.

Both projects were able to detect the modified record.

Questions :

1. How is execution_timestamp used? See our example, where data is returned although not expected according to the documentation.

2. What exactly is stored during a delta-sync ?

     A combination of :

• tenant-id
• project name
• channel name
• timestamp of last delta-sync ( deltasync.maxDateFromLastRun property?)
• ... ?

3. Where is this information stored, and can we view it ?

Many thanks & best regards,

Kevin

[arijitkumardas · Accepted solution]

Hi Kevin

You will need to add the deltasync.maxDateFromLastRun in the Advacned tab of your SFSF SOAP adapter (Use Additional Settings = 'X'). Please check if this has been done.

Please raise an incident with SuccessFactors support explaining the steps to them.

Regards

Arijit

[former_member207428 · Accepted solution]

Hi Arijit,

thanks for the response. A ticket has been created yesterday to get more information on the delta-sync behaviour.

Your suggestion, you mean like our current query ?

[arijitkumardas · Accepted solution]

Hi Kevin

Ok so maybe the Advanced tab is not visible in Eclipse / NWDS. So I suggest you deploy the iFLow to PI ID. Then check out the comms channel for the Advance tab.

Regards

Arijit

[arijitkumardas · Accepted solution]

Hi Kevin

Check this out (in case you already haven't) -

And here is what I am referring to (thank you for the pic!)

Regards

Arijit

[former_member207428]

This is the answer I got from SAP Support :

We are suspecting that you have not run the delta sync scenario more than once -> I did !

1. How is execution_timestamp used? See our example, where data is returned although not expected according to the documentation.

    Answer -- When an iflow with deltasync option is deployed, the first run will give all the data. Before completion the scenario, we will store the execution_timestamp if available in the database table. If not available we will store maximum lastmodified date in the database. The next run (for the same iflow) will form a query using this last stored max date. In your case you have run the iflow only once hence data is being returned. You re-run and it will not return any data or may return only delta data.

2. What exactly is stored during a delta-sync ?

    A combination of :

    tenant-id

    project name

    channel name

    timestamp of last delta-sync ( deltasync.maxDateFromLastRun property?)

    ... ?

    Answer -- We store either of one thing

    The 'execution_timestamp' if present else Maximum of all lastModifiedDate

3. Where is this information stored, and can we view it ?

    Answer -- It will be stored in internal table. It will not be available for you to view.

[Sriprasadsbhat]

Thanks Kevin for sharing the updates.

Regards,

Sriprasad Shivaram Bhat

[arijitkumardas]

Hi

Check out this blog on

Regards

Arijit Das