In a previous blog post, we took a simplified approach to explain the concept of keeping the core clean of a system.
I have developed a Python function (used as an analogy of an ERP module) to calculate the average time of fruit orders. I made sure to reserve some placeholders for customisations because Mr. Brown had specific requirements that go beyond the standard functionality.
If you don't see why an ERP extensibility topic is actually 1) a SAP BTP story 2) and is related to astronomy, this blog is for you.
What programming language has Mr. Brown's used to add his custom logic? (filter lead times based on a threshold?)
Python of course.
What if my function/system was written in Java?
Would it still be possible to write the custom logic in Python? Not really.
Same applies with the SAP ERP systems which are written in ABAP. So, if you want to add custom application logic inside the ERP you must use ABAP. This is why S/4 HANA systems are coming with an ABAP Runtime available embedded with similar placeholders like the one you show at the Python function to make sure you keep the core intact.
ABAP is extremely robust and runs productively in more than 100,000 SAP customer systems, where it enables enterprise-ready business applications and processes and reduces total cost of development due to its integrated, self-compiling nature. More details here.
So, does ABAP cover all my needs? What if...:
- You prefer Java instead of ABAP (or you just lack the skills)?
- You have the need to communicate financial dashboards to c-level?
- The customisation you have in mind requires using a Machine Learning algorithm?
- Your scenario involves a multi-approver workflow developed with BPM annotations?
- You are innovating with an mobile application intended for distribution to thousands of users?
OK stop you might say.
What all the above have to do with an ERP? Did you just came up with an imaginary list of use-cases? ERPs are transactional systems with business processes and well structured data models.
You are right , an ERP does not need all those applications to operate.
In an organisation, the ERP system it is a self-sustained system almost like the sun in a solar system, managing financials, inventory, and HR data. You dont need planets around it aka. extensions.
Yes that is correct, and congratulations you have the same dull solar system with the rest of the galaxy.
The sun (ERP system) doesn't "need" the planets (satellite applications) to exist, but their coexistence enhances the overall functionality and effectiveness of the solar system, just as satellite applications extend and improve the capabilities of the ERP system.
As an S/4 extension specialist you have the task to help organisations having a stable ERP while innovating and grow the solar system around it!
The five use cases mentioned above may appear to be addressing technical challenges, but in reality, they often revolve around broader considerations, such as:
- Skill Availability: For instance, if you lack ABAP expertise, how should you proceed? You need other Application Runtimes.
- Innovation and Experimentation: If you're a data-scientist how do you test a hypothesis using ERP data? You need a fast database and access to the latest ML algorithms.
- Scale fast: When facing the need to rapidly scale, like exposing securely ERP data to thousands of users via a mobile app, you need a mobile application toolkit.
You need planets for your ERP Solar system.
You need SAP BTP services.
Show me.
Lets address the first use-case from the list above by explaining how that would alter our approach extending the function from the first blog:
Only Python, having a placeholder to customise the code using...Python.
def calculate_average_lead_time(lead_times):
#The Fix
if not lead_times:
return 0
#This function will stay here FOREVER.
extend_functionality(lead_times)
total_lead_time = sum(lead_times)
num_cases = len(lead_times)
average_lead_time = total_lead_time / num_cases
return average_lead_time
#Custom code goes only here
def extend_functionality(lead_times):
threshold = 35
lead_times[:] = [time for time in lead_times if time <= threshold]
As you may see above the extend_functionality function was part of the same stack. We will change that to Node.js.
function extendFunctionality(leadTimes) {
const threshold = 35;
leadTimes = leadTimes.filter(time => time <= threshold);
return leadTimes;
}
The Node.js code above should run as a server, and the Python code should communicate with it via HTTP requests. The place where you would deploy the Node.js app (a new planet!) would be at an SAP BTP Application Runtime like for example SAP BTP Cloud Foundry Runtime.
You may go through this excellent entry-level SAP training to deploy your first application in Cloud Foundry. Take your time to understand the WHY you are doing what you are doing.
Let me explain what I mean by that. One of the steps to the above-mentioned training is to 'Create an instance of a service and bind it to your app'. Sounds easy and should be, but this small word there... 'bind' hides from you the concept of abstracting services which is super cool.
Spend some time to understand it by reading About Services in BTP. Remember! You are in a Platform now and in a PaaS environment, all external dependencies, such as databases, messaging systems, files systems, and so on, are services. In the Cloud Foundry environment, services are offered in a marketplace, from which users can create service instances on-demand.
The concept is clear. There is an API call now to an external application which is going to take care of filtering the apps.
An API call is not the same as if we had the custom code inside the same runtime (ABAB or Python or whatever). Of course not. Who is going to take care of the security between the two systems? Or any scalability issues? What tools do i need to develop a node.js app? Who is going to take care of the deployment? This is why you need SAP BTP!
So it is all about application and programming when we are extending an ERP?
Congratulations. If you have this question , you've reached 35% of your journey toward becoming an ERP extension specialist.
Let's introduce some additional complexity to achieve an additional 15% improvement.
Let’s expand our discussion with a Presentation Layer (UI) and a Database. Let's assume our application now has:
- A UI to create orders for fruits.
- A database to log:
- Orders e.g., 2 kilos of Apples and 3 kilos of Oranges
- Record the order date and the arrival date.
- Performing the lead time calculation with a press of a button
A basic representation of a data model for this application , could look like the following.
Each order can have multiple associated fruit order items, allowing for detailed tracking of ordered fruits and each fruit type can appear in multiple order items.
Here are the three tables with some sample data:
If you like what you see above , I did it with the latest and greatest Business Application Studio functionality to use Low Code to go from zero to a full-working 3-tier application.
Remember we are here because we are on the calculation of lead time business! This is what we do best.
How would you calculate that? Here is an SQL code sample:
SELECT AVG(TIMESTAMPDIFF(MINUTE, OrderDate, DeliveryDate))
AS AverageLeadTime
FROM Orders;
Amazing, no joins to tables, easy to understand and super-fast. I think our application will rock the world.
So, here is a question (addressing the second bullet from the use-cases list, to be able communicating financial results to c-level)
What is the total revenue generated by each fruit category (e.g., apples, bananas) over the last quarter?
EASY , lets work on some SQL.
SELECT
f.FruitName,
SUM(oi.Quantity * f.PricePerUnit) AS TotalRevenue
FROM
Orders AS o
JOIN
OrderItems AS oi ON o.OrderID = oi.OrderID
JOIN
Fruits AS f ON oi.FruitID = f.FruitID
WHERE
o.Status = 'Delivered'
AND o.OrderDate >= DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH) -- Rolling Last quarter
GROUP BY
f.FruitName
ORDER BY
TotalRevenue DESC;
Hm...the SQL query even if may seem well-structured, you would notice that it's relatively complex and could potentially lead to performance issues when dealing with larger datasets. This is expected because the initial data model was not designed to handle optimally queries. It was meant to address transactions!
Time to extend the data model.
An ERP or any other transactional application is designed with the primary purpose of managing transactions, and the data models are created with this objective in mind.
In some cases, the existing data model may not be ideal for accommodating certain analytical use-cases.
Ideally we would like to have a data model to address an analytical use-case with a simple query that can scale. Maybe some pre-aggregations to make the computational effort faster? Yet another planet for our ERPs solar system.
This is going to be explained in the next blog. While we have also have an overview , how SAP BTP is the platform you need if you have the need for a Machine Learning algorithm.
Congratulations, you've made it! Now you know the why and how to extend the application layer of an SAP ERP using SAP BTP, and we've just touched on the concept of extension that goes further into the data model!
Our list looks promising, with even more exciting topics to explore.
You prefer Java instead of ABAP (or you just lack the skills)?- You have the need to communicate financial dashboards to c-level?
- The customisation you have in mind requires using a Machine Learning algorithm?
- Your scenario involves a multi-approver workflow developed with BPM annotations?
- You are innovating with an mobile application intended for distribution to thousands of users?
Stay tuned for more content on becoming an S/4HANA extension expert.
- SAP Managed Tags:
