Application scenario of SAP BTP MTA application


The latest trends and advances in programming languages, software design architectures (such as microservices), protocols (such as OData), and the diversity of multi-layer and distributed deployment platforms have accelerated the trend of building applications from more, smaller, decoupled and diversified modules.

Under the microservice architecture, more and more business applications tend to be composed of multiple parts developed and deployed to various target runtime environments using different languages and technologies.

This diversity of application modules poses many life cycle challenges. Developing, deploying, and configuring all the individual parts of a complex application involves many steps, usually specific to the target platform or application server. The required services must be pre configured and supplied, and different modules must be “connected” together, configured and deployed on multiple platforms in a strict specific order. Usually, different tools are used repeatedly for testing, staging and production environments.

Zero downtime upgrade is another source of complexity.

SAP BTP has created the term multi-objective application (MTA) to express the diversity of life cycle management requirements, while other widely circulated terms in the industry, such as “distributed”, “multilingual”, “multi module”, “multi-layer” or “multi headed” applications, are not enough to express the diversity of this architecture. But in essence, MTA is only existingmulti-partNatural evolution of applications.

For example, the sap Hana XS advanced (xsa) application composed of UI and database modules and even application code is an example of MTA. Developers and administrators want to manage structured applications such as development, versioning, deployment, and operation as a logical unit.

Another typical MTA example is a Java EE application, which consists of beans, web and application modules, resource adapters, etc., all of which are subject to the same development life cycle and deployed across multiple computing layers.

The sap business technology platform introduces new distribution requirements for coordinated cross platform deployment. When acting as SaaS extension platform and adopting Fiori as a service (FAAS) concept, application developers need to distribute their applications across heterogeneous targets (Java VM, front-end server, SaaS back-end). Each target has its own deployment API and provides a carefully managed single application life cycle.

The increasing attention to microservice design principles, API management and the emergence of OData protocol as a rich service UI edge have further encouraged the proliferation of application modules developed in different languages, ides and construction methods.

But all these parts, UI, service and data model, must still run as a coherent application. There is little uniformity in deployment. Each runtime, application server or cloud framework manages multi-objective aspects in its own unique way by introducing various orchestration solutions (a large number of manifest files and formats, project JSON files, application descriptors, repositories, CTS + of sap, etc.)

PAAS such as cloud foundry have improved traditional application servers in a flexible way. They support various application runtime technologies through containerization. This brings more freedom to choose implementation technologies (Java, node.js, python, etc.). The application can be decomposed into multiple modules, which can be expanded independently, and the technology most suitable for each module can be selected. For example, in node The extensible request preprocessing agent implemented in JS may override the Java module that implements the business logic. While this is advantageous from a run-time perspective, the development and lifecycle management of such distributed applications becomes more difficult.