One of the most unique aspects regarding appropriately managing these other applications (beyond just SAP ECC) is that they are very network intensive. Networking Complexity Should Not Be Cause for Confusion The PI application is again another application that needs to be critically understood as its typically not architected like an ECC instance would be due to its functionality. The PI system itself doesn’t store a lot of data other than the logging of what it’s been doing, as it’s more of a transformative system which has data flows in and out of it, generally into SAP ECC. PI is a message service application designed to take data inputs from several other data sources and transform that data into it in a standard format. To be honest, today many MSP basis teams still find it very difficult to monitor BOBJ instances sufficiently.Īnother application that our team sees very prominently with SAP customers is Process Integration (PI) which again is also very unique in the way to which it is managed. The same unique internal features also applied to SAP BusinessObjects (BOBJ), that is not an ABAP instance, rather it’s an executable server based instance which in turn operates very differently. The internal workings of BW (although it’s still an ABAP based instance) also had more complexities that basis teams had to learn and understand in order to optimally manage. Beginning with building the architecture of the data warehouse instance, which was very different compared to creating an architecture of a standard application. BW was a little bit of a different ‘animal’ to maintain and monitor for basis teams all together. This all changed however, when SAP created more products, such as SAP Business Warehouse (BW). Making the daily management of these SAP systems fairly straightforward for any MSPs with ECC knowledge.
#Sap ecc meaning code
The application code however was different, but as far as the way your basis team managed these products it was almost identical to how a SAP ECC landscape would be managed in regards to transaction monitoring and overall system security. SAP released the relational SAP ECC database (a non-mainframe open systems architecture), then in the early 2000s, SAP began to produce products like CRM, SRM, BW, and several others.Most of those products, but not all, primarily functioned very similar to an ABAP instance, which allowed them to all operate internally exactly like any other ECC instance would. SAP ERP Central Component (ECC) was launched in the early 1990s, prior to that systems were all mainframe based. To better understand the issue of how only knowing SAP ECC can be very limiting let’s start with the history of how SAP applications have continued to evolve and become more complex over time. I will take an in-depth look into this issue with real-life examples from migrating SAP ECC to the cloud, running on SAP HANA and new application products that require much more technical knowledge far beyond the basics of SAP ECC. In this blog, we will examine the unique complexities that an ever-evolving SAP landscape faces, and what skills and experience are needed from your Managed Service Provider to adequately support your ERP applications long-term.