Welcome back to the blog post series on how to create your own Microsoft Teams extension for SAP solutions. Today’s ninth blog post will conclude the series and will give you some ideas on how to enhance the current sample application. Either by integrating further SAP source systems like SAP S/4HANA or adding advanced features provided by the SAP Business Technology Platform.
As explained in the first part (click here), this sample Microsoft Teams extension for SAP SuccessFactors will allow you to create leave requests right from within Microsoft Teams. It also provides features for managers to approve or reject leave requests. Again, this blog post series has a special focus on those customers who already have the SAP Business Technology Platform and would like to leverage the integration capabilities of the platform.
This last part of the blog post series will cover remaining topics like the integration of SAP S/4HANA as one example of how to enhance the current scenario. Furthermore, I will provide you a list of constraints to be aware of when using the sample application. These constraints and further ideas on how to enhance the current solution will be a good start for your own Microsoft Teams extension project. So, let’s see what’s left for this last blog post!
The integration with on-premise systems like SAP S/4HANA can be achieved quite simply with the current architecture. As SAP Cloud Integration is part of your SAP Business Technology Platform landscape, you can make use of available SAP Cloud Connector configurations in your SAP BTP subaccount.
Once you’ve configured your SAP Cloud Connector for issuing X.509 certificates accepted by your SAP systems, you can for example create an OData call in your integration flow and select the On-Premise Proxy Type combined with Principal Propagation authentication. A sample SAP Cloud Integration configuration (using the virtual host and port of the on-premise system) can be seen in the following screenshot.
If you compare the settings to a standard SAP BTP destination, you can see that the configuration is just the same. If required, you can also set the Location ID in case multiple SAP Cloud Connector instances are connected to your subaccount.
If you’re interested in further details on how to configure Principal Propagation in your SAP Cloud Connector, please check out the following links.
The setup of the required X.509 certificate usage is not trivial, so make sure you include experts from your SAP Basis team when it comes to changing critical settings in your SAP Cloud Connector and SAP S/4HANA systems.
Hint - If you do not need to rely on Principal Propagation, you can also start your on-premise integration scenario using the authentication type Basic, providing the name of a respective SAP Cloud Integration credential configuration.
Let me spend a few more words on the current solution approach and the reduced scope it covers. As this sample project is quite comprehensive and makes use of various tools and services, some abstractions and limitations had to be made. This also includes the chosen leave request business process, which (you can imagine) is far more complex than what this sample project can provide.
The SAP SuccessFactors leave request scenario was chosen as a running example for this blog post series. Whereas the basic leave request process is quite simple to understand and is working well for our use case, there are certain constraints that you need to be aware of before considering deployment in a productive environment.
Whereas a simple and standardized leave request (as in our example) is supported by public APIs of SAP SuccessFactors (click here), this will not apply to customer landscapes. Usually, the leave request process is highly customized with a lot of e.g., country specific fields and features. These are not covered by the standard APIs, which will lead to missing data and inconsistencies in case you choose to implement the scenario as-is within Microsoft Teams. The same applies for specific warnings and info messages, which are visible within SAP SuccessFactors but are not returned by the standard APIs. So, users might miss on critical information when creating a leave request in Microsoft Teams.
In case you would like to further build on this scenario, please make sure your use case requirements are satisfied by the standard SAP SuccessFactors APIs and test your code before deploying in a productive environment! As said, consider our sample use case as a food for thought and as an inspiration for your development needs. This sample scenario will not be supported or further enhanced by SAP and just serves the demonstration purposes!
As the provided sample solution is quite comprehensive and contains a lot of different architecture components, a list of important constraints is provided below. This list is not exhaustive but should give you some ideas of potential improvements and things to consider when building your productive extension. Also check the GitHub repository for known issues (click here) and keep limitations of the previous blog posts in mind.
As you might have noticed, the current sample solution is simple and supports a very basic leave request flow. In addition to the constraints listed above, I would also like to highlight some potential enhancement options for the current extension application.
Before this blog post series comes to an end, I would like to thank all colleagues involved in this project. No matter if it comes to development, refactoring, technical validations, or proof reading, your help was highly appreciated.
Besides the continuous support of my team here at SAP and experts from Microsoft, I would like to address some special thanks to Dante Alipio Jr, Kay Schmitteckert, Mariana Valencia and Nishnanth Payani who supported me on the last mile of validating and publishing this blog post series. Your effort is highly appreciated and I’m looking forward to a future collaboration!
I’d like to highlight Martin Räpple’s blog post series once again (click here). His excellent step-by-step guide has been a great inspiration for this blog post series and is worth reading!
Another inspiration for this blog post series was a Proof of Concept (PoC) between SAP, Microsoft, and our South Korean customer Doosan which focused on the Continuous Performance Management functionality of SAP SuccessFactors, allowing employees to give and request feedback using Microsoft Teams. You can find more information on this Co-innovation PoC in the link below.
https://news.sap.com/2022/01/sap-doosan-microsoft-delightful-digital-workplace/
Well, that’s it from my side! I appreciate your patience and following this blog post series to the very end. We are very interested to hear from your own experiences and ideas on other Microsoft Teams use cases for SAP solutions like SAP SuccessFactors or SAP S/4HANA. With a solid understanding of the presented architecture concepts and the provided sample application you should be well equipped to get your own scenario started.
Stay curious!
As explained in the first part (click here), this sample Microsoft Teams extension for SAP SuccessFactors will allow you to create leave requests right from within Microsoft Teams. It also provides features for managers to approve or reject leave requests. Again, this blog post series has a special focus on those customers who already have the SAP Business Technology Platform and would like to leverage the integration capabilities of the platform.
- Preface and scenario introduction (click here)
- Target application features (click here)
- Requirements and application architecture (click here)
- SAP BTP subaccount configuration and test users (click here)
- SAP SuccessFactors instance setup (click here)
- Set up your SAP Cloud Integration instance (click here)
- Get your Microsoft Azure settings ready (click here)
- Deploy your Microsoft Teams extension (click here)
- Improvement ideas and further topics (this blog post)
- Access on-premise systems like SAP S/4HANA
- Scope of the current solution approach
- Other enhancement scenarios
This last part of the blog post series will cover remaining topics like the integration of SAP S/4HANA as one example of how to enhance the current scenario. Furthermore, I will provide you a list of constraints to be aware of when using the sample application. These constraints and further ideas on how to enhance the current solution will be a good start for your own Microsoft Teams extension project. So, let’s see what’s left for this last blog post!
Access on-premise systems like SAP S/4HANA
The integration with on-premise systems like SAP S/4HANA can be achieved quite simply with the current architecture. As SAP Cloud Integration is part of your SAP Business Technology Platform landscape, you can make use of available SAP Cloud Connector configurations in your SAP BTP subaccount.
Once you’ve configured your SAP Cloud Connector for issuing X.509 certificates accepted by your SAP systems, you can for example create an OData call in your integration flow and select the On-Premise Proxy Type combined with Principal Propagation authentication. A sample SAP Cloud Integration configuration (using the virtual host and port of the on-premise system) can be seen in the following screenshot.
Principal Propagation for on-premises systems
If you compare the settings to a standard SAP BTP destination, you can see that the configuration is just the same. If required, you can also set the Location ID in case multiple SAP Cloud Connector instances are connected to your subaccount.
SAP BTP Destination for Principal Propagation
If you’re interested in further details on how to configure Principal Propagation in your SAP Cloud Connector, please check out the following links.
- Blog post by Claus Burgaard (click here)
- Blog post by Martin Räpple (click here)
- SAP Help documentation (click here)
The setup of the required X.509 certificate usage is not trivial, so make sure you include experts from your SAP Basis team when it comes to changing critical settings in your SAP Cloud Connector and SAP S/4HANA systems.
Hint - If you do not need to rely on Principal Propagation, you can also start your on-premise integration scenario using the authentication type Basic, providing the name of a respective SAP Cloud Integration credential configuration.
Scope of the current solution approach
Let me spend a few more words on the current solution approach and the reduced scope it covers. As this sample project is quite comprehensive and makes use of various tools and services, some abstractions and limitations had to be made. This also includes the chosen leave request business process, which (you can imagine) is far more complex than what this sample project can provide.
The leave request scenario
The SAP SuccessFactors leave request scenario was chosen as a running example for this blog post series. Whereas the basic leave request process is quite simple to understand and is working well for our use case, there are certain constraints that you need to be aware of before considering deployment in a productive environment.
Whereas a simple and standardized leave request (as in our example) is supported by public APIs of SAP SuccessFactors (click here), this will not apply to customer landscapes. Usually, the leave request process is highly customized with a lot of e.g., country specific fields and features. These are not covered by the standard APIs, which will lead to missing data and inconsistencies in case you choose to implement the scenario as-is within Microsoft Teams. The same applies for specific warnings and info messages, which are visible within SAP SuccessFactors but are not returned by the standard APIs. So, users might miss on critical information when creating a leave request in Microsoft Teams.
In case you would like to further build on this scenario, please make sure your use case requirements are satisfied by the standard SAP SuccessFactors APIs and test your code before deploying in a productive environment! As said, consider our sample use case as a food for thought and as an inspiration for your development needs. This sample scenario will not be supported or further enhanced by SAP and just serves the demonstration purposes!
Constraints of the sample scenario
As the provided sample solution is quite comprehensive and contains a lot of different architecture components, a list of important constraints is provided below. This list is not exhaustive but should give you some ideas of potential improvements and things to consider when building your productive extension. Also check the GitHub repository for known issues (click here) and keep limitations of the previous blog posts in mind.
- Very basic leave request process not taking edge cases into account.
➤ Features missing like e.g., file upload, correct balance calculation, comments, display of existing leave requests, cancel leave requests, multiple approval steps, … - User mapping between SAP SuccessFactors and Azure Active Directory.
➤In a productive scenario, a user provisioning between Azure Active Directory
and SAP SuccessFactors might be required to have a common user basis. - No sophisticated error handling/forwarding implemented was implemented.
➤ Error messages from SAP SuccessFactors are not forwarded to the client. - Application was developed as a monolith containing backend and user interface components.
➤ For scaling and maintenance reasons, a split might be suitable. - Powerful technical user was used for SAP SuccessFactors API calls without user contexts.
➤ Should be a dedicated technical user with the least possible privileges. - Usage of Basic authentication in Event Connector.
➤ Because of issues during development, Basic authentication was used for the Event Connector whereas the Client Credential approach should be preferred if possible. - No dedicated role for the extension application used in SAP Cloud Integration.
➤ A separate role which is also used in the role collection mapping would make sense in a productive scenario. This limits the integration flows accessible to Microsoft Teams users. - CSRF checks not enabled for POST request endpoints in SAP Cloud Integration.
➤ This has been disabled for simplification purposes but should definitely be enabled in a productive scenario. - Silent authentication is not supported by tabs and messaging extensions based on adaptive cards. Only the usage of adaptive cards for standard authentication is possible.
➤This might result in multiple login requests.
Enhancement scenarios for the sample scenario
As you might have noticed, the current sample solution is simple and supports a very basic leave request flow. In addition to the constraints listed above, I would also like to highlight some potential enhancement options for the current extension application.
- Extension Application features
The implemented bot is quite restricted from a feature perspective and not very smart when it comes to recognizing user commands. This could be a potential enhancement option to think about. Same applies to further tabs (click here) or messaging extensions (click here). So, why not trying to code your own tab using native React components or even a custom task module for the messaging context? Also check out the SAP Conversational AI services offerings when it comes to bot related topics (click here). - SAP Cloud Integration
Make use of advanced scenarios and possibilities offered by SAP Cloud Integration like combining multiple SAP source systems in an integration flow with just a few clicks. Imagine a scenario in which a leave request is approved in Microsoft Teams and your integration flow automatically assigns an alternative approver in SAP Concur for the respective time-frame. Or instantly changes your mailing address to your home details in SAP S/4HANA? Check out the available missions on SAP Integration Suite for more ideas (click here). - SAP Event Mesh
SAP Event Mesh (click here) could be used to store events from various SAP solutions in a queue and make them available for multiple consumers in your SAP BTP environment. Currently the notifications are sent straight from SAP SuccessFactors to Microsoft Teams. Using SAP Event Mesh in between would preserve them for various scenarios being built on the same event. - SAP Process Automation / SAP Workflow Management
Make use of features provided by SAP’s automation and workflow solutions to trigger processes based on the interactions between your Microsoft Teams and your extension application (click here or here). - Enterprise Readiness features
The sample application does not yet provide relevant enterprise readiness features. You could e.g., include the SAP Application Logging Service (click here) to save and store important logs of your app. Another service worth considering is the Application Autoscaler (click here) to make sure your app is also available in scenarios of increased interest. To simplify the development and deployment process of your app, you can include the SAP Continuous Integration and Delivery (click here) service combined with the SAP Cloud Transport Management (click here) offering in case of a multi layered landscape (Dev, Test, Production). - SAP Private Link Service
Include the SAP Private Link Service (click here) for scenarios in which you would like to request data from your SAP systems hosted in Microsoft Azure like SAP S/4HANA. This replaces the need for SAP Cloud Connector in certain circumstances by securely connecting your SAP BTP subaccount with your own VNET in Microsoft Azure. Also, other Azure services like database services can be securely consumed this way. You can find more information on the usage of SAP Private Link in the following SAP Discovery Center mission (click here) and the associated GitHub repository (click here). - Onboarding Features
Currently every user needs to install the application manually from the Microsoft Teams App Store. Without adding the app to your profile, you will not receive any notification. As there are options to provide apps to your organization users automatically, these could be used to pre-install the extension (click here).
Special Thanks
Before this blog post series comes to an end, I would like to thank all colleagues involved in this project. No matter if it comes to development, refactoring, technical validations, or proof reading, your help was highly appreciated.
Besides the continuous support of my team here at SAP and experts from Microsoft, I would like to address some special thanks to Dante Alipio Jr, Kay Schmitteckert, Mariana Valencia and Nishnanth Payani who supported me on the last mile of validating and publishing this blog post series. Your effort is highly appreciated and I’m looking forward to a future collaboration!
I’d like to highlight Martin Räpple’s blog post series once again (click here). His excellent step-by-step guide has been a great inspiration for this blog post series and is worth reading!
Another inspiration for this blog post series was a Proof of Concept (PoC) between SAP, Microsoft, and our South Korean customer Doosan which focused on the Continuous Performance Management functionality of SAP SuccessFactors, allowing employees to give and request feedback using Microsoft Teams. You can find more information on this Co-innovation PoC in the link below.
https://news.sap.com/2022/01/sap-doosan-microsoft-delightful-digital-workplace/
What’s next?
Well, that’s it from my side! I appreciate your patience and following this blog post series to the very end. We are very interested to hear from your own experiences and ideas on other Microsoft Teams use cases for SAP solutions like SAP SuccessFactors or SAP S/4HANA. With a solid understanding of the presented architecture concepts and the provided sample application you should be well equipped to get your own scenario started.
Stay curious!
- SAP Managed Tags:
