SEARCH

Search Results for ""

Data Migration: Journey to the Cloud – Part 3

 

Posted by Jess Spaull, SAP SuccessFactors Consultant at Hula Partners, now GP Strategies

 

Welcome back!  In my final installment of this three part series, I will cover the options available for Exporting data from Employee Central (EC) for the purposes of data validation.

The time to complete data validation can often be misjudged as it is a high time and resource consuming process.  While business teams will be involved in validating the data, using an automated approach can add efficiencies to this process including the ability to test 100% of the migrated data immediately after the first test migration.  Data validation determines the integrity of the migrated data through a process of comparing the migrated records in the destination system to the source system and is a checkpoint to ensure the data migrated is complete and usable.

Once the process of migrating data into Employee Central is complete, data validation testing can begin.  But how will you get the data out of Employee Central?  There are many reporting options available within SuccessFactors Employee Central that will not be covered in this blog.  Instead, I will list the various methods that have worked for me in the past:

 

Located in the Admin Center:

o   Export Users – use this to export the User Data File (UDF) and confirm all employees in scope to be migrated exist in EC with the correct status, either active or inactive.

o   Import and Export data – select ‘export data’ as the action and export the data from any generic or custom object.  The output will provide a direct dump of live data from the database of the object selected.  The output will be in CSV format.  There is no customizing these reports.

Located in the Report Center:

o   Ad hoc Reports – use this to build your own reports to export live data from any standard object, like job information, personal information etc.  The reports are quick and easy to build with options to merge data from more than one data set and/or from different domains if desired.  The output can be saved in multiple formats such CSV, Excel and more.

o   Advanced Reporting – existing in the Online Report Designer (ORD), this reporting tool is available for all EC customers and needs to be activated in your stance before use.  It is an ODS (Operational Data Store) database which allows you to build queries and reports with any EC object – standard, generic, foundation and custom MDF objects.  It may take longer to set up the reports initially as ORD requires skill training and sometimes performance can be unpredictable and poor.

Located in the Integration Center:

  My Integrations – make use of SAP’s built-in templates available from the Integration Catalog or create or own and then deploy and monitor these simple file-based integrations to your third party system via the Integration Center.  These outbound files can be manually executed or scheduled using a variety of different trigger, source and destination types using different formats.  Ideal if you want to send outbound files to a secure server location via SFTP or web services like REST or SOAP.

Using the SF API or ODATA APIs to extract data using an external system:

o   Some of the ETL tools mentioned in part 2 of this blog series used to import data into Employee Central can also be used to export data out of Employee Central, like SAP Data Services.  An automated reconciliation framework can be built in parallel with your migration framework to provide high-level migration results in a timely manner.

o   The ODATA API can be used to extract data directly into Microsoft Excel or Google Sheets, making exporting data even easier.  More information on how to do this can be found here.

 

Data validation is important and cannot be overlooked. The tools and resources available to you will aid in determining the best ways to extract data from Employee Central for your project. Feel free to reach out to me at x-jspaull@gpstrategies.com with any questions.

 

To read the first two installments of this series, please click here.

 

 

 

Hula Partners is now part of GP Strategies. To learn more, see here.


How Different are Boomi and SAP Cloud Platform Integration (SCPI)?

 

Posted by Kevin Kane, Senior Consultant at Hula Partners, now GP Strategies

 

It seems more and more customers are choosing SAP Cloud Platform Integration (SCPI) as an alternative to Dell Boomi for integration between SAP ERP and SuccessFactors Employee Central. This presents integration consultants in the space with the opportunity to learn a new technology. Unsurprisingly, developers with Boomi experience will recognize commonalities within SCPI at a high level but will find differences up close. Let’s quickly compare the two.

 

3 Key Differences

Structure Mapping

SCPI funnels everything toward XML. Mapping between XML and CSV, a common scenario for EC customers, is a multi-step process in SCPI. Instead of putting an XML profile and a CSV profile on opposite sides of a mapping in Boomi, SCPI requires an XML-to-XML mapping and then a separate step to convert from XML to CSV.

Versioning

This is one key difference between SCPI and Boomi. In Boomi, every time the user saves a change to a process, a new version is generated that can be viewed or reverted. In SCPI, however, artifacts have buttons for “Save” as well as “Save as version.” Distinguishing between saving and version generation has the obvious drawback of making it difficult to revert to just the right version. However, for users who are constantly saving (never a bad idea), the upshot is that the user has the option to keep a cleaner history with only essential versions.

Click-and-Drag Method

The SCPI interface has some UI quirks that distinguish it from Boomi. Boomi’s click-and-drag method of placing components into a process can prove to be a hard habit to unlearn when moving to SCPI’s click-and-click method. While this example is hopefully an easy “day one” takeaway for new SCPI users, it’s representative of several simple differences that can prove time-consuming for those coming from a Boomi background.

 

2 Similarities

Field Mapping

Other than SCPI’s bias toward XML, individual field mapping is similar on the two platforms. SCPI has a different layout for working on one field mapping at a time while still seeing the larger picture, but the differences are more cosmetic than fundamental.

Scripting

Boomi developers versed in Groovy script will be pleased to find that it’s also supported in SCPI. The SCPI web UI doesn’t always handle syntax issues gracefully, so you may want to copy/paste from a text editor to avoid losing work when you’re making changes.

 

 

All in all, SCPI and Boomi are similar enough for Boomi developers to transition to the newer platform pretty quickly. Hopefully seeing a rundown of some similarities and differences will give you the confidence to take a swing at it.

 

For questions or a more in depth explanation, please contact me at kkane1@gpstrategies.com.

 

 

 

Hula Partners is now part of GP Strategies Corporation. Please see here to learn more.