Aryan Chugh

Designed and developed a custom SAP Fiori application to give business users real-time and historical visibility into the status of SAP CPI data load processes, eliminating the need for end users or support staff to manually navigate SAP's technical monitoring transaction (SRT_UTIL) to check integration status. This app was built as a companion tool to a broader SAP integration where business-triggered data loads are pushed through CPI into a target SAP system, giving users a way to independently confirm whether their data load had completed successfully, without depending on technical teams. My Role & Contribution: As the Fiori and ABAP developer, I owned the end-to-end build, from the front-end application down to the backend data service. I built a Fiori application where users specify a date and time range, either for live, in-progress monitoring or for historical lookups, and retrieve the status of all data load logs within that range. On the backend, I developed a custom OData service that queries a custom table tracking CPI message status, filtering by user and the selected time range, and returns the corresponding results. For live sessions, I implemented an automated polling engine in the UI5 controller that refreshes every 60 seconds, intelligently distinguishing between "no activity yet," "in progress," "completed successfully," and "error" states, with configurable retry limits to avoid indefinite polling. I designed a status table that surfaces records needing attention first, such as errors and in-progress items, so users can immediately spot problems without scrolling through completed records. Impact: Reduced reliance on technical teams for both routine live status checks and historical log lookups, gave functional stakeholders self-service visibility into data load health across any time range, and standardized error escalation with clear, actionable messaging, improving turnaround time for identifying and resolving failed data pushes.

Designed and developed a custom SAP Fiori application enabling business users to trigger a governed, parameter-driven financial data load into SAP Group Reporting, as part of a cross-functional integration connecting Fiori, SAP CPI, and SAP Datasphere to S/4HANA. My Role & Contribution:
 As the Fiori and ABAP developer on this project, I owned the front-end application, backend OData services, and the proxy layer responsible for securely triggering the downstream integration: Built a Fiori application with searchable, multi-select value help dialogs (backed by custom OData services) allowing users to accurately select master data values — such as Fiscal Year, Fiscal Period, Consolidation Unit, and Version — with live search and pre-selected state retention across repeated lookups. Developed a custom OData V2 service in ABAP to capture and validate user-selected parameters before triggering the integration. Generated and implemented a SOAP consumer Proxy Class in ABAP (SPROXY) from a WSDL file provided by the CPI team, structuring the outbound payload to match the CPI-defined interface. Coordinated with the Basis team, who configured SOAMANAGER for the logical port and connection settings, to ensure the proxy call reached the correct CPI endpoint reliably. Worked with the CPI team to align on interface structure and payload requirements, supporting end-to-end testing of the trigger mechanism. Integration Workflow:
 Fiori → OData → ABAP Proxy Class → SOAMANAGER (Basis-configured) → CPI From there, the CPI team's iFlow queried and filtered the relevant dataset from SAP Datasphere and posted it into the ACDOCU table in SAP Group Reporting (S/4HANA). Impact:
 Delivered a self-service Fiori front end that replaced manual, technically-gated data requests — giving finance users a governed, parameter-driven way to initiate data loads while ensuring accurate, validated data was reliably handed off to downstream integration and reporting systems.