Real-Time Scenario Challenges and Solutioning for Action within Automation using S/4HANA On-Premise

[mohit_bansal3]

As an SAP BTP Platform & Governance Architect, my daily work revolves around crafting BTP solutions with a strong emphasis on maintaining a clean ERP core system, typically S/4HANA. This focus is particularly relevant for many of our customers who currently utilize on-premise S/4HANA systems.

These customers / projects seek guidance on optimal solutions that seamlessly integrate with their overall enterprise architecture strategy, prioritizing a clean ERP core. Here's where SAP Build Process Automation (BPA) steps in as a critical tool. We are leveraging BPA to develop numerous process automation solutions for our valued customers.

Pre-requisites & Assumptions:

This blog dives deeper into SAP build process automation and one specific problem statement. To get the most out of this content, we'll assume you have a foundational understanding of these core concepts:

• SAP Build Process Automation: The overall framework for automating tasks within the SAP build process. Please refer standard SAP help document here.
• Actions: Individual building blocks used to call api within the build process / automation.
• Automation Steps: Sequences of actions strung together to achieve a desired outcome in the build process.
• Destination configuration for SAP Build process automation.

Problem Statement:

This blog post tackles  challenge: integrating secure API calls to on-premise S/4HANA systems within unattended automation steps of SAP Build Process Automation (SBPA) & perform the exception handling as well. The twist ?The backend system isn't directly exposed to the external world.

"Calling On-Premise S/4HANA APIs in Secure Unattended  Desktop Agent in Automation Step  within SAP Build Process Automation when  backend  is not exposed to outside world."

We'll explore how to achieve this by leveraging the combined capabilities of  SBPA Actions & Automation & destination set up..

S/4HANA API Integration via Automation Studio: Challenges Encountered

This blog post details our experience integrating a standard S/4HANA API with automation step within SAP Business Process Automation (BPA) . While initial configuration steps proceeded smoothly, we encountered challenges during automation execution.

Configuration Steps:

1. API Exposure: A standard S/4HANA API was published in the API Hub, providing access for integration purposes.
2. Destination Creation: A destination was created with Basic Authentication for secure communication. The backend system was connected via a cloud connector using the "On-premise" type.
3. SAP BPA Lobby Configuration: The destination was configured within the SAP BPA Lobby to establish the connection with S/4HANA.
4. Action Development and Testing: An action was created based on the standard API. Action simulation confirmed successful interaction with the API.
5. Automation Step Creation: An automation step was created and configured to consume the developed action.
6. Local Agent Setup: For testing purposes, a local desktop agent was installed on the local machine to execute the automation.

Challenge and Next Steps:

Up to this point, the configuration appeared functional. However, during execution of the automation with the automation step, the process failed. This signifies a potential issue that requires further investigation and resolution.

Root Cause Analysis: Understanding Why Direct Action Simulation Succeeded But Automation Step Failed

This post dives into the root cause of an observed discrepancy in behavior between a directly simulated action and the same action executed within an automation step.

Scenario:

• Step 4 above involves an action that interacts with an on-premises system.
• Simulating this action directly works as expected.

Analysis:

• The key difference lies in the execution context.
• Direct action simulation leverages the cloud connector, which is configured to reach the on-premises system.

Root Cause:

• Automation steps are executed by the desktop agent, which resides on-premises and not within the cloud environment.
• The destination configuration designed for the cloud connector isn't compatible with the desktop agent's execution context.

Resolution:

• To ensure the action functions correctly within the automation step, the destination configuration needs to be adjusted to align with the desktop agent's execution environment.

Troubleshooting On Premise API S/4HANA Communication with Desktop Agent: A Step-by-Step Approach

The Desktop Agent on the VM fails to connect to the S/4HANA system in the BTP cockpit.

Solution:

1. Desktop Agent Installation: Ensure the Desktop Agent is installed on the VM within the same network as the S/4HANA on premise system. This facilitates seamless communication.

2. Unattended Desktop Agent Configuration: Configure the Desktop Agent installed in VM in unattended mode to establish a connection with BTP.

3. Destination Creation: Create a new destination in BTP cockpit.. Set the proxy type to "Internet" and provide the internal host URL (not the virtual host) as the destination host. This redirects communication to the appropriate internal resource.

4. SBPA Destination Re-configuration: Update the existing SBPA destination to point to the newly created destination (step 3). This ensures the Desktop Agent utilizes the correct communication channel.

5. Automation Execution with Trace Enabled: Run the automation with trace logging enabled. This will capture detailed information about the communication process, including API responses to test result.

6. Monitor Trace Logs: Analyze the trace logs to identify any errors or issues that might be hindering the connection. The presence of API responses in the logs indicates successful communication between the Desktop Agent and the S/4HANA system 😀 😀

This post explores a significant design improvement that eliminates the need for complex workarounds when integrating on-premise APIs into automation workflows.

Previously, limitations existed when interacting with on-premise APIs. These limitations often necessitated solutions like CAP wrappers, which added unnecessary complexity.

Conclusion:

This new design removes these limitations, allowing for S4HANA on premise API consumption within automation. This offers several key benefits:

• Improved Exception Handling: The design facilitates easier and more efficient handling of API-generated exceptions within the automation framework.
• Simplified Integration: Direct consumption streamlines the integration process, eliminating the need for additional tools or wrappers.Previously, limitations existed when interacting with on-premise APIs. These limitations often necessitated solutions like CAP wrappers, which added unnecessary complexity.

This improved design offers a significant step forward for businesses looking to streamline automation processes and effectively leverage on-premise APIs.

I encourage you to share your thoughts and experiences in the comments below!

Further Discussion:

Feel free to connect with me to discuss this topic further via email or LinkedIn (links in bio).

Regards,

Mohit Bansal