Objectives
This lesson describes the definition and implementation of integration best practices and procedures. Specific recommendations and guidelines are provided to ensure efficient and effective integration of systems and processes.
This lesson contains the following topics:
This unit provides an introduction to integration best practices. It covers the definition and implementation of best practices and procedures for designing and optimizing integration solutions.
After you have designed your hybrid integration platform in the previous phase, you will continue with the definition of best practices for the implementation of the respective integration scenarios.
The SAP Integration Solution Advisory Methodology describes vendor-independent concepts for integration best practices that have proven to be useful and valuable for SAP customers and partners. These are supplemented by examples in the SAP context.
The goal of this phase is to manage and secure the implementation of integration scenarios. Documented and shared best practices are useful for decentralized or distributed integration development teams. They help to agree on common integration standards, which increase the level of integration maturity of the organization.
At the end of this phase, you have created the following assets:
Specific recommendations and guidelines for integration are described. These dos and don'ts provide practical guidance on how to avoid common mistakes and promote best practices.
Define "golden rules" for integration development to standardize integration scenarios with higher quality.
Integration dos and don'ts are easy-to-apply principles about aspects to consider or avoid when designing and implementing integration scenarios. When defining such integration dos and don'ts, you should focus on the most important rules. Otherwise, there is a high risk that the integration developers will not follow all the rules. The SAP Integration Solution Advisory Methodology attempts to define integration rules for integration styles. If necessary, you can provide detailed guidance (for example, for integration technologies) as part of integration development guidelines.
The following list shows an example of the dos and don'ts that apply to the process integration style, including the reasons why.
| Dos and don'ts | Reason |
|---|---|
| Leverage integration packages (content) wherever possible. | Reduces integration development effort. |
| Decouple business applications through asynchronous messaging and events. | Better scaling runtime behavior and resilience. |
| Use synchronous calls only in selected use cases. | Risk of slow, unreliable or no responses. |
| Avoid a tight coupling of applications. | Negative impact on resilience, availability, maintenance of the integration scenario. |
| Prefer (near) real-time distribution of data over batch-oriented processes. | Ensures that data is up to date in connected business applications. |
| Avoid chaining of too many integration runtime components | Makes it more difficult to monitor and operate such integration scenarios. |
| When defining integration rules, you must also consider customer context factors that may lead to deviations from general best practices. |
The do's and don'ts of integration are usually defined by an integration architect.
Use the template-based approach to define integration measures. Integration Assessment does not support the SAP Integration Solution Advisory Methodology. Integration dos and don'ts refer to the design and implementation of integration scenarios that are not addressed by Integration Assessment.
In the header, enter an integration style for which you want to define integration rules:
Make sure that you do not define more than 10 integration rules in total.
The creation of architecture blueprints is described. These blueprints provide visual representations and guidelines for the design and implementation of integration solutions.
Describe the scope of integration technologies, including relationships and features using architecture diagrams.
Architecture blueprints provide a model solution for an architecture in a specific domain. For the enterprise integration domain, an architecture blueprint is a visual representation that shows the components of an integration architecture, including their relationship and integration touch points with business applications. Further details such as interface technologies, security features, and data types used must be added if they are essential to an IT architecture.
Following the concepts of this methodology, you create your architectural designs at the level of an integration use case pattern and an integration domain. Sometimes, there is more than one architectural option for an integration architecture, for example, due to a business-specific or infrastructure-specific solution design.
The following figure shows an architectural blueprint example:
It is recommended to work with the new Solution Diagram Guideline. The solution diagrams of the SAP Business Technology Platform offer abstract representations of technical landscapes at a high level.
They help customers understand the range of BTP services and solutions offered by SAP and how they integrate with other SAP products.
These domain-specific diagrams show solution scenarios across IT landscapes by visualizing SAP BTP services, systems, environments, and their dependencies.
The BTP solution diagrams focus on creating visually appealing and insightful high-level solution architectures based on the Horizon visual theme for SAP Fiori.
You can use Power Point or draw.io for realization. In both cases, you can import the required icons.
Customized development guidelines are created. These guidelines provide specific instructions and standards for the development and implementation of integration solutions.
Development guidelines Provide detailed guidance to integration developers by creating development guidelines for integration technologies.
Integration development guidelines (often referred to as integration manuals, integration best practices, or similar) are a common means of sharing integration best practices across distributed development teams. The goal of such guidelines is to ensure that integration processes are robustly designed and implemented to protect your organization's business-critical processes. Implementation guidelines cover both technical and organizational aspects of integration development. Examples of the latter include naming conventions for developed integration artifacts, processes for integration management and quality assurance.
An implementation guideline must cover the following best practices:
Use the customized offers for architects:
Log in to track your progress & complete quizzes