RH_SFI_TRIGGER_EMPL_DATA_REPL - SF

[vishnu_pallamreddy]

Hi All,

We are going to execute the report RH_SFI_TRIGGER_EMPL_DATA_REPL in ECC to send employee data to SF.

What are the requirements?

As per my understanding for this report we no need of PI Channels like SOAP channel right?

We need to pick the file and place it in SF folder right?

File to File is required here right?

Any one please suggest me...

[Muniyappan · Accepted solution]

if you run this report, it will create files in SAP app server.

so it will be file to file without any mapping. this applies to only emp scenario.

receiver side it will be SFTP.

sender side it will be file or sftp adapter based on your company settings. if basis can mount ECC folder into SAP PI, then you can use file adapter with NFS protocol.

or if you can write scripts and run ECC, then you no need for PI, as scripts can send the files to SFTP. this is rare case.

[Former Member]

This message was moderated.

[Muniyappan]

check luke's comment in the below blog. it may cause confusion. you better decide which approach is recommended.

[vishnu_pallamreddy]

Hi Muni,

So it is File NFS to SF SFTP.

Actually my clients are interested in PGP encryption and decryption for security purpose.

Please let me know whether File adapter supports PGP encryption or not?

So no need of mappings.

Actually my understanding is in sender side we can encrypt and in receiver side we can decrypt right?

Please tell me about PGP encrypt and decrypt?

[Muniyappan]

you can encrypt using file adapter.

you have to check with SF, on decryption should be done using pi for if SF can do the decryption and load the data.

[vishnu_pallamreddy]

Thank you Muni,

I will check with SF team on decryption.

[vishnu_pallamreddy]

Hi Muni,

I have confirmed with SF team.

Encryption will happen in PI.

Decryption will happen in SF.

So please confirm me on below?

So sender File adapter with Encryption Module and Receiver  SFTP adapter with normal configuration right?

[Muniyappan]

that is correct.

[vadimklimov]

Hi Vishnu,

Program RH_SFI_TRIGGER_EMPL_DATA_REPL only supports file based integration with SuccessFactors - it is used to trigger generation of a file with employee data extract, which is then uploaded to SuccessFactors.

If you would like to benefit from using PI system for this integration scenario, it is recommended to use program RH_SFI_SYNCHRONIZE_EMPL_DATA instead of RH_SFI_TRIGGER_EMPL_DATA_REPL. RH_SFI_SYNCHRONIZE_EMPL_DATA supports transmission of employee data both using files and using PI (option "Middleware" on its selection screen) - when using an option for middleware based integration with SuccessFactors, RH_SFI_SYNCHRONIZE_EMPL_DATA will use outbound proxy service interface for sending data to PI, thus you will need a proxy (SOAP-XI) sender communication channel in your PI system for this integration.

Please note that you should not execute both these programs - only one of them should be chosen and used.

Regards,

Vadim

[vishnu_pallamreddy]

Hi Muni and vadim,

if i run this report RH_SFI_SYNCHRONIZE_EMPL_DATA where data will be saved in SF system?

[vadimklimov]

Vishnu, we don't really have visibility of persistence layer of SuccessFactors (since this is a cloud solution from customer perspective and customers are not intended to go deep into technical details of its realization to integrate with it). PI calls SuccessFactors API (being exposed as a web service) and pushes data or polls data from SuccessFactors, but it doesn't directly access any persistence layer of SuccessFactors.

It is possible to access SuccessFactors web based monitoring toolset and check which transactions were processed there, but still you don't get direct access to persistence layer.

Regards,

Vadim

[Muniyappan]

Hi Vadim,

which one is better to use? file based or soap based services. little bit confused here. we are in the add on 3.0 stage. is it recommended to use API based services?

all methods has some dis advantages.

looks like every time report RH_SFI_TRIGGER_EMPL_DATA_REPL generates the full load and sends out.

Proxy to soap scenario runs extra two interfaces for each call(login and log out).

if we use SFSF adapter, there is no standard content available.

more over, when you interact with successfactors consultant about SF integration, all come to their mind is "csv" file.They tell Integration consultant, hey you just have to send the csv file to SF. SF will pick and process. This brings a lot of confusion to integration consultant.

[vadimklimov]

Hi Muni,

Based on recommendations provided in SAP Help materials for "Integration Add-On for SAP ERP HCM and SuccessFactors HCM Suite" in part of employee data replication (refer to SuccessFactors Integration: Employee Data Replication - Integration Add-On for SAP ERP HCM and Succe...), usage of RH_SFI_SYNCHRONIZE_EMPL_DATA is a preferred option in comparison with RH_SFI_TRIGGER_EMPL_DATA_REPL. RH_SFI_SYNCHRONIZE_EMPL_DATA provides features for delta extraction and integration with SuccessFactors not only via files, but also via middleware (both are not available in RH_SFI_TRIGGER_EMPL_DATA_REPL).

You are right, usage of RH_SFI_SYNCHRONIZE_EMPL_DATA in combination with middleware based integration will involve three interfaces:

• SFSFSessionHandlingLoginQueryResult_Out - to login to SuccessFactors and obtain a session ID;
• SFSFUserUpsertRequestConfirmation_Out - to transmit extracted employee data;
• SFSFSessionHandlingLogoutQueryResult_Out - to log off from SuccessFactors.

All these interfaces are provided as a part of SAP add-on for integration between HCM and SuccessFactors, and RH_SFI_TRIGGER_EMPL_DATA_REPL implements calls of these three interfaces in required sequence (SFSFSessionHandlingLoginQueryResult_Out, followed by SFSFUserUpsertRequestConfirmation_Out and SFSFSessionHandlingLogoutQueryResult_Out), and since login and logout interfaces are very lightweight, they shouldn't bring much overhead to entire integration.

You are correct: not all scenarios which are currently delivered in SAP add-on content, make use of SuccessFactors adapter currently, so drawback is necessity of usage of Axis adapter for quite a lot of them at the moment, if we would like to utilize SAP standard configuration as much possible.

In my opinion, even though usage of Axis based solution requires extra overhead related to deployment of Axis libraries and involves two extra interfaces, I would prefer that one in order to make use of SAP standard configuration scenarios delivered in add-on as much as possible - at least for current being, until they are not migrated to SuccessFactors adapter. If some time in the future they will be complemented or replaced by those using SuccessFactors adapter and delivered in SAP add-on, I would definitely prefer SuccessFactors adapter based rather than Axis adapter based. File based integration is the least preferred method by me in this particular scenario between discussed three options.

Regards,

Vadim

[Muniyappan]

Thank you Vadim.