SAP Development

Aug 27 2020

Lessons Learnt from Implementing SuccessFactors Onboarding 2.0

When I started implementing SuccessFactors Onboarding 2.0 late in 2019 it was very new, only just General Availability and no customers were live as yet. There were definitely a few speed bumps as consultants and customers navigated through this new product! Here’s what I learnt along the way, which I hope will make for a smoother transition for other customers.

Adopt Standard System Processes, Rather Than Customising the System

Be willing to adopt rather than adapt the system. Instead of trying to implement multiple complex processes with the current limitations – keep it simple. The product isn’t at full parity with Onboarding 1.0 as yet and more features and functionality will continue to be rolled out.

When I started to implement Onboarding 2.0 late last year I was very fortunate to have a client who was both flexible and willing to change their processes so they could adopt the standard functionality Onboarding 2.0 provides.

Given the product was so new at that stage, this was really critical to the success of the implementation, and the approach I’d still urge clients to follow. There’s more growth to come in how much we can customise the system to suit individual needs, so be open to starting with a standard process and building out from there.

As an example, to include compliance forms and features (currently only available for Australia and the UK, with some US support planned for release in 2H 2020) you need to use the standard-delivered process variant. The next release will provide enhanced support to tailor processes to your needs while still supporting compliance features.

This will give more flexibility to have multiple processes configured for different scenarios, such as removing the “New Recruit Data Review” validation step at the beginning of the process. This step kicks off the onboardee paperwork and tasks but is really just a validation of the same information already provided, we could streamline the process by removing a potential bottleneck while waiting on a user to action a step that may not add much value.

Less Mapping But Less Flexibility

With Onboarding 1.0 we configure data mapping from Recruiting to Onboarding, then Onboarding to Employee Central, making the data flow slightly more complex and with more effort involved.

In Onboarding 2.0 we map directly from Recruiting to Employee Central, but with the simplification comes less flexibility. The Onboarding data model is configured using the same system functionality as adding contingent worker, apprentice, or other types of employees.

But it’s ONE data model for ALL onboardees.

While Onboarding 1.0 doesn’t support hire of contingent workers either, it did provide more flexibility to define separate onboarding workflows for each type of employee – the limitation being that they all end up in Manage Pending Recruits to be hired as employees.

For some customers this option works fine if they aren’t using Contingent Workforce functionality. For others Discovery has previously implemented a custom development at the end of the Onboarding process to hire contractors in “Add Contingent Worker” rather than an employee hire.

Now we have one set of data that can be captured for all Onboardees, with no capability to show/hide fields, or to include/exclude sections depending on the employee type. This becomes a problem when you consider that you then have National ID, Bank Details, etc included for contractors; information which isn’t usually required for these types of staff.

Support for contingent workers and other employee types is a critical improvement I’d like to see on the Roadmap for release soon, so customers can seamlessly manage all recruits via an integrated recruiting and onboarding process.

Custom Data Collection & Reporting

With Onboarding 2.0 we can create custom data collection objects to capture information from onboardees in addition to the key hire-related data included in the personal paperwork step, such as uniform requirements. This works well to cater for non-standard data scenarios, however, the data captured is only available via:

Reporting in People Analytics Embedded Edition
By mapping into a custom form which is only accessible in Document Management
With a custom extract using APIs or Integration Centre, adding extra effort to the project

Ideally this information would be visible in the Employee File after completion of the Onboarding process, but a system limitation prevents this currently. The next best solution is standard system reporting capability, and to do this you will need People Analytics Embedded Edition.

PAEE is the latest suite-wide reporting and insights tool being rolled out for SuccessFactors, which has a prerequisite of SAP Cloud Identity Authentication (IAS and IPS). If you haven’t already upgraded to these features it’s worth considering as part of your implementation, while the Onboarding/Offboarding Dashboards provide an overview of activities, you won’t get in-depth analysis of your processes.

Notifications & Form Requirements

Onboarding 2.0 delivers “Email Services”, a standard set of notification triggers and preconfigured templates. While it’s nice to have standard content available as a starting point, most customer requirements will include the use of standard and custom tokens (data already captured during the process), attachments to notifications, ability to send to external email addresses, and more flexibility in triggers; none of which are currently available.

Again, this is an adopt rather than adapt approach, while we wait for the product to develop. It looks like attachment support for notifications is expected in the next release and I hope a few more nice surprises here too.

In some scenarios we can work around these limitations, e.g. attachments, by providing documents to the onboardee in a custom homepage tile for easy access. We can also provide policies and documents for review and signature during the paperwork process. SAP’s standard eSignature or integration with DocuSign provides online signature support.

Consider how many policies/forms are required to be included in this step, as the more data to be mapped and the more forms required, adds extra effort to the project.

Existing SuccessFactors Employee Central Customers

For customers already using SuccessFactors Employee Central, factor in time to review and update existing permissions and business rules. One of the big improvements of Onboarding 2.0 is that it utilises platform business rules rather than “advanced conditions” and role-based permissions, rather than the current syncing process for Onboarding 1.0.

This provides much more granularity and consistency in role-based permissions, as well as making it easier for client system admins to maintain, but with that comes more complexity in getting it right. Existing roles need to be updated to ensure that we aren’t giving too much access, or not enough, and that they work in conjunction with any new Onboarding permissions.

Business rules also need to be reviewed. Where we might be validating certain data fields on save when adding a new employee, these same rules will be triggered during onboarding steps and may need tweaking.

Benefits and Upcoming Improvements

What customers will gain from implementing Onboarding 2.0 is:

A user interface and experience more consistent with the rest of the suite
Tighter integration with Employee Central, which should only continue to improve with subsequent releases
Simplified approach with no need for user, permission, and foundation data syncs; use of To Do tile tasks; capability to map standard foundation objects such as Division, Department, Cost Centre, Location from Recruiting.
Improved Offboarding process with new tasks including Knowledge Transfer Plans
On/Offboarding Dashboards to view all tasks in one place and flexibility in assigning those tasks to different user groups, unlike Onboarding 1.0
All UI screens built to be mobile-responsive
SuccessFactors Employee Central and Recruiting modules aren’t prerequisites, integration with third-party systems managed by either SAP CPI or SuccessFactors Integration Center, using SuccessFactors OData API (EC mini-master IS required).

As well as expected fixes and improvements to business rule support and crossboarding processes, the current roadmap for the 2H 2020 release includes the following:

Attachment support for Email Services
Ability to generate person id with EC business rules; currently does not comply with customer requirements for different number ranges
Support for creating custom processes with compliance steps, enabling steps to be skipped or reordered
US compliance support for US Federal (W-4) and state withholding forms, restricted availability for I-9

With future releases it seems unlikely that Onboarding 1.0 will continue to experience much growth, while getting in on the ground floor with Onboarding 2.0 will be the key to gaining benefits from new features.

Final Thoughts

Onboarding 1.0 has no confirmed end-of-support date currently, it’s not going anywhere just yet and compliance updates will continue to be implemented.
Onboarding 1.0 and 2.0 can be run in a hybrid approach, existing customers could implement 2.0 for Australian employees only, with the remainder of countries continuing to be processed with 1.0.
Capability to utilise migration tools is proposed for late 2021, if you’re ready now – don’t wait.

Aug 13 2020

SAP CPI and SAP SuccessFactors Monitoring EP02: The one where CPI writes logs to Execution Manager

This blog post originally appeared in the SAP Community on 12/08/2020.

Discovery Consulting was recently involved in the global SAP SuccessFactors Implementation Design Principles (IDP) workshop on SAP SuccessFactors Integration patterns. Our practice of logging the results of SAP CPI iFlows into SAP SuccessFactors Execution Manager was picked up by the group as a potential SAP recommended best practice! Hopefully, we will see something come out from SAP in the future around this. However, whilst we wait for that to happen – here’s some details about how we at Discovery use this integration best practice to help our clients support their SAP SuccessFactors instances and be better equipped to deal with issues if and when they occur.

This post is targeted at an audience of SAP Cloud Integration developers and the SAP SuccessFactors administrator that they work with. It is a quite technical post and gives some great detail on the solutions that we use with our customers.

Firstly, a little background. Too often in the past I have seen support calls from customers about SAP SuccessFactors to/from SAP ERP (and other systems) integrations and a request to “find out what went wrong.” Many/most of these issues could be solved if only the SAP SuccessFactors administrators had access to any error/success messages that the integrations were producing. The aim of these blogs is to show how easy it is to incorporate logging to SAP SuccessFactors Execution Manager into all your SAP CPI integrations so that admins and developers have a simple way to monitor all SAP SuccessFactors integrations.

This post is the second in a series about this logging – you can read the first post which gives some details about the Execution Manager and using OData APIs to update it here:

SAP CPI and Successfactors Monitoring EP01: The one with the Execution Manager Dashboard

Enough background – on with the show!

From my first post we, hopefully, now have an idea of how easy it is to log information into the Execution Manager Dashboard in SAP SuccessFactors. It is now time to put our knowledge to use. As Dale Carnegie once said,

“Knowledge isn’t power until it’s applied.“,

It’s time for us to finally go ahead and see a bigger picture of how exactly we can harness the Execution Manager to our advantage. In this post, I’ll be focusing on how I implemented the Execution Manager in SAP Cloud Platform Integration iFlow.

Bird’s eye view of the implementation

This implementation consists of an iFlow and a simple reusable groovy script to generate EMEvent payload groovy script. Just to make things a bit modular here, I broke the iFlow into the following integration processes:

Main integration process,
Few local integration processes for the following:
2.1 populating demo data(in external parameters and body) to imitate the process of generating data to be posted to Execution Manager Dashboard, and
2.2 sending data to Execution Manager Dashboard using HTTP adapter
a separate local integration process for exception handling, and
a groovy script to generate EMEvent payload to be sent to Execution Manager Dashboard in SAP SuccessFactors.

Now before I get into the details, I would like to quote an expression by Tess Flanders in 1911 that fits here perfectly,

“Use a picture. It’s worth a thousand words“.

So here, I share with you how exactly the implementation looks like when it is ready to log everything we need in the Execution Manager Dashboard **drumrolls**

Fig.1: iFlow to log data in Execution Manager Dashboard

Digging into the iFlow

Now let’s see what’s really happening here in the iFlow above (I’ll try explaining things in the order I’ve mentioned above).

1. Main Integration Process

Fig.2: Main integration process

a) In this example, every execution of the main integration process logs 3 separate events into the execution manager dashboard, i.e. START – data/error/warning/failure (you can log as many events representing these between a START and END event) – END :Initializing the external properties for EMEvent payload. Here’s what the ‘initialize properties’ step looks like. I have included a sample payload to log a single event from my previous post and how it maps to the properties initialized.

Fig.3: Properties defined for EMEvent and EMMonitoredProcess payload

note: The EMMonitoredProcess payload needs to remain the same, as a single execution of the iFlow represents a process in Execution manager. All the events logged under a single process are clubbed together enclosed within a ‘START’ and an ‘END’ event.

b) Once the properties are initialized, the properties for the EMEvent payload needs to be changed for every event we wish to log. The most important one here is the ‘event_type’ property as it decides the type of event logged into the execution manager. So, the next step here is to change the event_type in a content modifier to ‘START’ as we initially need to log a START event.

c) The next step in line is to log the data that matters in the form of multiple events showing data that is required to be presented in the Execution Manager Dashboard. That is where the ‘log data’ step comes in, which triggers the Log data integration process mentioned in the next section. This integration process can be used to fire multiple events as the iFlow carries on its execution. In this case, the iFlow is designed to log a single event of the type INFO to represent a portion of information.

d) Once, all the data/error/warnings have been logged during the execution, there is another enclosing event that needs to be logged. You guessed it right, END event it is 🙂

If we fail to log the END event for a process, the process in all would have an ‘IN_PROGRESS’ state rather than the expected ‘COMPLETED’ state (please refer to my previous blog if you need a reference to different scenarios and the final process state for each).

2. Local Integration Processes

2.1 Log Data integration process

Fig.4: Generating data to log

This local integration flow is to represent a process/set of processes that execute during the lifecycle of an integration flow where the iFlow does what it is actually designed to do (pick data from source A, transform, write into destination B). This could be a single local integration flow, or a set of flows to get your job done. This is where we log the events depending on what data is really required by the business.

2.2 Execution Manager Logger integration process

Fig.5: Generating and logging payload to Execution Manager Dashboard

This local integration flow is principally responsible for 2 tasks:

Executing a script which generates a payload to log an event by using the external properties and body populated by components before this integration process is called.

Firing a HTTP call to SAP SuccessFactors Execution Manager Dashboard to log the event.

3. Global Exception Handler

Fig.6: Handling errors and exceptions

While working on the solution, there were times when the iFlow during its execution ran into errors such as errors with the script, HTTP connection issues, etc. that caused the iFlow to fail. But how does that impact our logging and why should we care?
As mentioned before, it is important to log an ‘END’ event for every execution to ensure the EMMonitoredProcess does not end up in a ‘IN_PROGRESS’ state even when the actual execution of the iFlow has stopped/failed.

Therefore, this local integration process is to take care of all the errors/exceptions/failures that occur during the execution and ensuring that proper error messages are logged in to the Execution Manager, followed by an ‘END’ event.

4. EMEvent payload generating groovy script

As simple as it should be, this script picks up data from the external properties and populates them into one single JSON payload consisting of an EMEvent and an EMMonitoringProcess.

Script 1: Generating EMEvent payload

*disclaimer: Script provided for discussion purposes only, any attempt to use this script or a variation of it in your own integrations is at your own risk. No fitness for use in any particular purpose is, or should be, implied.**

**this said, some of our experienced technical team would be more than happy to help you work with this framework to build out the best solutions for your SAP SuccessFactors instances if you’d like us work with you!

Reaping the results

Just for the sake of demonstration, I have considered executing the iFlow 4 times, once for each ‘event_type’ and its impact on the ‘final process state’ of the EMMonitoredProcess/execution as mentioned below.

Use Case Scenario	final Process State
Use Case A: event 1- START event 2- INFO event 3- END	COMPLETED_SUCCESSFULLY
Use Case B: event 1- START event 2- ERROR event 3- END	COMPLETED_WITH_ERRORS
Use Case C: event 1- START event 2- WARNING event 3- END	COMPLETED_WITH_WARNINGS
Use Case D: event 1- START event 2- INFO event 3- FAILED	FAILED

Table 1: EMEvent use case scenarios and their impact on final process state

And this is how the scenarios look like when executed one after the other:

Fig.7: Execution Manager Dashboard after logging the events

But how do I debug this? How do I trace a Process/execution back to the message in CPI?

If you scroll back up to Fig.3 and look at the EMMonitoredProcess payload, you will notice an attribute called ‘processInstanceId’. Process Instance ID as the name suggests, is to uniquely identify a single execution/process which clubs together several events under it.
But don’t we have something similar in SAP CPI to identify a particular execution of an artifact/iFlow?

As mentioned in the Developer’s Guide (2020), every message that travels across in an iFlow has a few header fields by default which has information about the iFlow/artifact they belong to. One such header field is ‘SAP_MessageProcessingLogID’ which uniquely identifies a particular message/execution of the iFlow and can be found under the Label MessageID in CPI’s ‘Monitor Message Processing’ page.

Let me show you below, how the ‘processInstanceId’ external property that we populated with the field ‘SAP_MessageProcessingLogID’ in CPI can be correlated with Execution Manager Dashboard’s ‘Process Instance ID’.

Fig.8: Mapping an EMMonitoredProcess to an execution in SAP CPI

Conclusion

With everything in place, I hope you can see how this is an effective and relatively simple way to standardize the monitoring of integration flows in SAP CPI for an SAP SuccessFactors admin. It does this in a way that collates all the integrations associated with your SAP SuccessFactors instance in a single place to enable the developers and admins to monitor everything from a single dashboard.

This not only helps the developers but the business users who need to check the overall performance of the Integrations without having to access SAP CPI and learn how to navigate that platform as well as SAP SuccessFactors.

That’s all Folks!

I hope that you enjoyed these posts. I’d like to thank my colleagues and their collective efforts for helping me pull these together. It’s great to work with a team that continues to innovate, extend and make SuccessFactors integration as easy to use as possible for all our customers.

Thanks for your time!

References

Developer’s Guide, 2020. Developer’s Guide: Managing Integration Content. [Online]
Available at: help.sap.com
[Accessed 11-08-2020].

Jun 23 2020

Using SAP Fieldglass to Set Up Your External Workforce Management

What Is External Workforce Management?

The external workforce is revolutionising the way business gets done. While once upon a time there needed to be an in-house department or — at the very least — an in-house specialist required to handle each role, this has not proved cost-effective. This results in rigid business structures, out of which expansion and evolution were difficult simply because businesses could not draw upon the required resources.

The digital age has brought with it a more flexible approach to the workforce and how this workforce is managed. Surveys suggest that around 44 per cent of the total workforce is now external, and this level is increasing.

How SAP Fieldglass Makes All the Difference

SAP Fieldglass provides an overarching digital solution from which to manage all aspects of your external workforce, from creating jobs and filling roles to filing invoices and paying wages. With Fieldglass, you know:

Who’s working for you
What they are working on
Where they are located
Which of your facilities they are accessing
How much they are getting paid

By answering these key questions, your business will be able to:

Simplify the engagement of the external teams and operatives needed to fulfil key roles within your business
Structure your approach to the external labour force and to payment (supported by automated features)
Ensure security and compliance, even if no direct payment is being made (for example, you know who has access to your facilities)

These are the key tenets of SAP Fieldglass, but there are other benefits you can expect from the solution, too:

Increased efficiency through process standardisation
Cost savings through rate controls on external workers
Full visibility from a single data repository coupled with powerful reporting
Legal and regulatory compliance

Sap Fieldglass 2 Man On Construction Site During Daytime 159306

How to Set Up External Workforce Management with Fieldglass

Setting Up and Getting Started with Fieldglass

The user begins the process by setting up SAP Fieldglass. This is achieved via a four-step procedure.

Register with the Ariba and Fieldglass networks.

SAP uses the Ariba network to handle communication and transfer of files between Fieldglass and SAP ERP. This means that users will need to register for both networks before they can begin.

Set up the Fieldglass account.

With the registration on both networks now confirmed, the user simply needs to complete the set-up on their Fieldglass account. This includes reviewing settings and parameters and making sure these reflect your own needs for Fieldglass.

Provide training and education to users on how to utilise the Fieldglass account.

In order for Fieldglass to be effective, your teams need to be able to process work items in the Fieldglass account. This means individual team members should have the training and support needed to use Fieldglass efficiently and effectively, managing the external workforce in a way that achieves targets in terms of flexibility and agility.

Provide training and education to external teams and other members of the external workforce.

Using Fieldglass to connect with remote workers is a two-way channel. The external workforce needs to be able to respond to support requests and posted tasks, just in the same way as your internal teams need to be able to access the platform to post these tasks. External teams also need to be able to access timesheets and other resources. Make sure that such teams are able to access this effectively.

Follow the Category Management Checklist

Before you can begin to properly manage your external workforce, you need to follow SAP Fieldglass’s category management checklist. Take a look at the following points and ready your business for external workforce management.

Bring the top levels of management onboard.

Upper management needs to be on board with the project from day one, providing their complete support each and every step of the way. Hold initial meetings to make sure that this is the case, and schedule regular meetings in the future to keep all levels of the company engaged in the process.

Manage external talent under a centralised platform.

This is the SAP Fieldglass solution. Fieldglass provides businesses with a centralised platform they can use to keep on top of the external workforce effectively. We’ve already taken a look at the initial set-up phase for Fieldglass, so make sure that this is completed.

Agree on clear responsibilities.

Each member of the team who is cleared to use Fieldglass for work orders and other management tasks must agree on their responsibilities ahead of time. Make sure every duty and every task is covered, and that every member of the team is clear on what they need to do.

Expand strategic cooperation with staffing agencies.

There may be times when your business needs are particularly acute, and you require more external support to plug the gaps. There may also be times when these needs are less intense and urgent. Connecting with staffing agencies via the Fieldglass portal will ensure that your needs are met.

Put each process through rigorous testing.

The category management checklist is almost complete, but you still need to make sure that proper testing has been carried out. Think about how you will be using SAP Fieldglass and put each process through its paces.

Defining Your Supplier Management Level

The next phase is to define which level of supplier management you are currently at so you can chart your progress over time. The levels are:

Decentralised

At the decentralised level, you will have several suppliers that you will manage internally. Procurement will be handled on an ad hoc basis.

Preferred Supplier

At this level, you will have a selective set of providers and contracts or service-level agreements (SLAs) with each of these suppliers.

Master Vendor

At this level, you may only have a single supplier who manages other suppliers on your behalf. This means only one point of contact and direct cost savings on bill rates via customised SLAs.

Managed Service Provider

A business at this level has only one contact point for their suppliers. They will leverage direct cost savings on the billing rate, leading to a better management of total spend.

Total Talent Management

This is the level everyone is aiming for, characterised by a reflexive and agile management set-up that is achieved via the Fieldglass platform. At this stage, suppliers are engaged and managed as and when required, with no gaps or shortfalls.

With your current level defined, you gain a clearer idea of what you need to do to reach the next level. In this sense, working with SAP Fieldglass can give you a better understanding of how your business is operating.

To learn more about how to get the best from Fieldglass or how to make the solution your go-to for external workforce management, reach out to our team to learn more.

Feb 14 2020

SAP CPI and Successfactors Monitoring EP01: The one with the Execution Manager Dashboard

This blog post originally appeared in the SAP Community on 11/02/2020.

Note: This post is specifically targeted to my fellow SAP CPI developers who design SuccessFactors integration solutions and need a one-stop-shop for monitoring iflows (for developers/admins/managers) without having to go through SAP CPI logs and traces*

Background

Being fairly new to the SAP CPI space, I usually am a bit more careful just to ensure our clients get not only the solutions they want but the solutions they need (don’t we all?). In which case it would be appropriate to mention how exasperating it has been on my end to provide them with an integration solution which shows them what they really need to see (the logs – appropriate success, failure and exception messages).

There have been a few amazing blog posts earlier on how to effectively log messages, like the one here by Sven Müller where he harnesses the power of groovy scripts to append messages to a log file during runtime and then adding the message as an attachment once an iflow finishes the job. I found it to be the most reliable and easiest way an integration developer could trace what exactly happened for iflows that could execute for as long as 10 minutes (the trace functionality stops tracing data after first 10 minutes) or more.

On one hand, where I found this approach to be the most suitable for me in most of the cases, I always wondered if we could provide our clients a one-stop-shop for monitoring their standard SuccessFactors integrations along with custom SAP CPI based integrations without even feeling the need to dive deep into the dark side of SAP CPI, the ‘Monitor Message Processing’ page.

While working on a project for one of our clients, I was suggested by my mentor to look into the Execution Manager framework and figure out if we could go that extra mile to give our customers what they exactly need to monitor the iflow execution, without having to go into SAP CPI to figure out where things went wrong.

Therefore, in this article I would first like to share my findings on Execution Manager and if it’s possible to harness its superpowers in SAP SuccessFactors to further be able to use it in our SAP CPI iflows and make monitoring with SuccessFactors a lot simpler and tidier.

Execution Manager and Custom Integration

The fact that SuccessFactors welcomes custom integrations with wide-open arms, opens a whole new world of possibilities for monitoring the behaviour of our custom solutions from within SuccessFactors instances itself. The Execution Manager in SuccessFactors is the one-stop-shop which provides a dashboard to give you an overview of all the custom and standard integration processes communicating with your SuccessFactors instance.

To navigate to Execution Manager Dashboard, simply type ‘Execution Manager’ in the search box on your SuccessFactors HomePage –> select ‘Execution Manager Dashboard‘ from the options list and you’ll be welcomed by a page similar to one shown below.

Fig.1 SuccessFactors Execution Manager Dashboard

The navigation panel on the left-hand side allows you to choose from standard (Integration Center), scheduled and custom integrations (Middleware Integrations).
The main section of the dashboard shows all the ‘Processes’ being/already executed with their Process States, Time Stamps and other details related to the processes.

The beauty of the Execution Manager is that SuccessFactors provides OData services for writing (logging) into the Execution Manager from an external middleware and takes care of how to display the data **bliss**.

Talking further about these processes, it is important to be able to log multiple messages during its execution. Therefore, if you click on the arrow displayed at the right-hand side of each process, it further leads you to a more detailed view of the logs and activities (called ‘Events’) that have occurred during the execution, as shown below.

SuccessFactors - Events Logged in a Process

Fig.2 Events Logged in a Process

The relation between Events (EMEvent) and Processes (EMMonitoredProcess)

Each message logged as a part of a process is actually a ‘POST’ call to an entity called EMEvent (Entity Manager Event). Several such EMEvents carry a reference to a process (a single execution of a particular process) which resides in SuccessFactors as an instance of EMMonitoredProcess entity.

To create an EMMonitoredProcess, you need to create an EMEvent payload with the details of the EMMonitoredProcess you wish to create. Once a process is created, you can log several EMEvents for that process by including the details to the process that you created. For every EMEvent you create, SuccessFactors would group it within the process you’ve pointed to in the payload (further down the line in this series of articles, each such process would be created by an iflow execution in SAP CPI).

To make it easier, here’s an Entity Relationship Diagram for your reference.

Fig.3 EMMonitoredProcess and related entities

Furthermore, for giving users more information about a particular message/event you can create EMEventAttribute(s) for every EMEvent.

Trying it out!

Here’s a sample payload to create an instance of an an EMMonitoredProcess, which has an Event (message) logged with an attribute.

{
“eventName”: “Begin iflow”,
“eventType”: “START”,
“eventDescription”: “My iflow just started”,
“eventTime”: “/Date(1581046477000+0000)/”,
“eventAttributes”: {
“__metadata”:{
“uri”: “EMEventAttribute”
},
“name”:”details”,
“value”:”log a message and provide details”
},
“process”:{
“processDefinitionId”: “DiscoveryConsultingDemo”,
“processInstanceId”: “6ggfd9C6dbcf47648eefe633487af282”,
“processType”: “INTEGRATION”,
“processDefinitionName”: “DemoA”,
“processInstanceName”: “ProcessName”
}
}

Now let’s try creating a process and add an event to it using postman first.

SuccesFactors - Events Logged in a Process

Fig.4 Events being logged in a Process

Great Success!

Now let’s check out what our Execution Manager Dashboard looks like:

SucceesFcators - Logged events for a process

Fig.5 Logged events for a process

A few things to take care of:

Make sure your ProcessInstanceId remains consistent for a group of EMEvents you wish to log under a single EMMonitoredProcess.
The final value of the Process State is determined when event is either of type START, END or FAILED (see table below for different possible values of EMEvent and the corresponding Process State value).

Table 1: EMEvent use-cases

Conclusion

Now, after trying out the Execution Manager framework it is quite certain that logging from SAP CPI is just a matter of making a few calls from within your iflow to Execution Manager and you can log all you want for the developer (like yourself), administrators and managers, all at one place.

Further Steps

If this intrigued you and you wonder how can this be implemented within SAP CPI, checkout the 2nd episode of this series where I have shared my approach of using this framework along with Exception Sub-processes to ensure the messages from SAP CPI are logged in the Execution Manager without making the iFlows messy and scary to debug