Integration Logic Vs Business Logic

[prateek]

I have to write it down now. After receiving several queries and watching the community skeptic about a basic yet critical integration approach, I thought of writing a few lines about one of the very basic concept of Integration - the "Business Logic Vs the Integration Logic". Some of you must already be crystal clear about it and I agree that it is quite basic too. However, I think it will be of help for at least a small cluster of Integration community.

The difference between this Business Logic does not only apply for PI, but for any Integration landscape within an organization. Therefore as we grow as a real "Consultant" we need to know the difference and should be firm about our stand point while designing an Integration landscape. It is very well possible that both these terms are used interchangeably within an organization. However, the sooner you identify and clarify the terminology as an Architect or Consultant, the better would it be for your Integration Landscape.

Definitions

Business logic refers to the business process requirement which will be used to generate an output or consume an input. Business logic ideally resides in the end systems. For example, for a utility industry the business process to create a meter read request can be termed as a Business Logic. Another example could be the process of creating a sales order in ECC based on some input data.

An Integration Logic refers to the transformation and modification requirements which arise when different systems communicate with each other. For example, for a manufacturing industry when an electronic invoice is sent to the customer, there could be a requirement to concatenate tax and discount before it is sent. Another example could be the internal customer number within SAP has to be converted to external customer number before sending an invoice to the customers.

Confusion Begins:

An Integration Logic can take following two forms:

1. Business Logic: In some cases, it is possible that the Business logic turns into Integration logic. For example, before sending an invoice, look up for the currency exchange rate might be required in ECC system. Although this is a business logic send the invoice in the currency required by partner, it should be implemented within PI as this requirement does not typically appears as part of the core business process.
2. Pure Integration Logic: These are cases when the message format generated by sender are unacceptable to the receiver partner. In this case, to make the message format aligned with what receiver expects, the logic is implemented in PI. For example, a receiver systems always expects delivery date and time to be concatenated and the sender can only send them separately.

Approach:

There is a very thin line between the kinds of logic and there usage within the organization. Ideally the Business logic should reside in end systems (source or target) and the Integration logic should reside in the Middleware (SAP PI). Although it is best to follow the ideal approach, we know that this is never 100% feasible.

My personal suggestion would be to follow the quote "Be good and get good". Here is how you apply the quote in real life:

1. For some cases, when the end system is unable to make changes at their end, business logic can be incorporated into PI. This is where you "Be Good". However, as a PI Consultant, it must be insisted to incorporate the core business logic at the end systems as far as possible.
2. There could be cases where it could be very complicated to make changes within PI. For example, to fulfillac the Integration logic, you may at times have to rebuild almost the entire business process logic in PI similar to that of a sender system. Then you can utilize the "Get good" part and request the end system to implement the logic. This is very commonly seen when we ask the ABAP team to add the logic in user exits or BaDIs. :grin:

Summary:

While designing the interface, give a good amount of focus on the best approach to segregate your interface development between PI and the end systems. As a Consultant or Architect, your approach should be the ideal one as mentioned above. Tweaks are always needed, but using them wisely can lead to a much clearer and "logically" designed Integration landscape.