Business Object and Integrations

This construction has these advantages:

• The integration party is not confronted with the technical implementation of the LN functionality, nor with the complexities and limitations that apply on that level. For example, no matter how many tables are required to store the data, all tables are accessible through the business object, while, at the same time, the business object hides these tables, and simply presents the integration party with the entry points to read or store this data.
• Because the internal LN functionality is not addressed directly, this functionality can be changed without affecting the integration, as long as backward compatibility is guaranteed. For example, the code of a table field can be changed, while the external representation of this field in the business object remains the same. BusinessPartnerAddress remains BusinessPartnerAddress. Of course, an update of the business object is required to link BusinessPartnerAddress to the new table code, but an integration party can still use that name.
• The user interface of the business object is defined in compliance with international standards, such as OAGIS and RosettaNet. This terminology is understood in the business field and enables a quick recognition of data and functionality.
• The adoption of XML as communication language between LN and an integration party provides a very flexible and application-independent way to structure the information that is communicated.