How to replicate your Fiori Inbox in Microsoft Teams

Using Looply you can replicate your Fiori Inbox in Teams, and it’s fast and easy.

Putting outstanding workitems in the face of those users who are not logged into SAP Work Zone / Fiori LaunchPad /  SAPGUI can accelerate processes and lead to a host of other benefits.

We can build the solution in 4 steps.

[1] Consider the trigger points.

You have options.  You might run a background job periodically to update Teams.  This is easy to set up, but resource-intensive if you decide to run it every few minutes instead of, say, twice per day.

You could trigger the Teams card from SAP workflow, so that you can be sure that the card is updated when a workitem is created and/or completed.  This would mean adding tasks to each workflow, so it’s considerably more work, but much less resource intensive, as there is no background job to run.

You could trigger the Teams card from SAP events – in exactly the same way that workflows are triggered, so that each time a critical workflow is triggered then the Teams card is created or updated.  This is less work to set up, but potentially more complex because you might be triggering the Teams card before the workflow has determined the user. (So you might want to build in a 60-second wait.)

Of course, you could choose more than one approach, as some processes are more critical than others.  For example, you might trigger a card update at the end of specific workflow processes, and also schedule a job twice a day.

In this example we’ll write a simple ABAP program to schedule as a background job. (See step 4.)

[2] Build your Looply Workflow.

Pure notification workflows tend to be very simple, as basically Looply is being passed some data, which it is mapping to Teams card fields, and push the card to the identified user.

In this example we’re going to add a button to enable the user to remove the card, and also the capability to either CREATE a new card where one doesn’t exist, or UPDATE an existing card.

This way there will never be more than one notification card for a user.

Let’s break this down.

1. When the workflow is triggered (and no existing card is in place) then the first step is to trigger a new card.
2. The card could be closed manually (‘MS Teams Response’) or it could be subsequently updated from another SAP call (‘External Response')
3. For the ‘External Response’ we need to capture the new data and push it into the data schema (‘payload’) that the card is mapped to. We do this mapping in the ‘Override Payload’ step.
4. Then we Update the card, using the new data.
5. Again, the user could close the card manually, or more data might be received from SAP. If more data is supplied then we update the schema from the data returned, and loop back to where we update the card.

 [3] Build your Adaptive Card in Looply

The card is really simple as there are very few variables.  It is basically a list of actions with URLS / deep links to point back to Fiori Inbox items.

This card comprises 5 containers, which are used to group and style fields:

1. Heading
2. User name
3. Item count
4. Item table
5. Action buttons

The item table has just one field, for description, which is bound to “[${wi_text}](${wi_full})” such that the workitem text (wi_text) is displayed with the URL to the Workitem for action (wi_full).

[4] Build the SAP trigger

There are two parts to this. Firstly the Process Determination table should be configured, adding the Looply workflow ID.

Secondly, the trigger program:

Here we have created a simple selection screen just with the user name as the selection option.

The program logic is:

For each selected user:

• Get details using BAPI_USER_GET_DETAILS
• Get inbox items using SAP_WAPI_CREATE_WORKLIST
• For each item, build the URL to the workitem in Fiori Inbox
• Prepare data fields for the card in an internal table
• Read the Looply Process Determination table
• Trigger Looply workflow using /LOOPLY/CORE=>TRIGGER_WF for Outbound Scenario.  This tries to start a new workflow for the user, but fails if there is already a workflow running.
• If that fails trigger Looply workflow using /LOOPLY/CORE=>TRIGGER_WF for Resume.  This will continue the Looply workflow from the current step.