Customizing

On this and the following pages you will find a deep dive into the architecture of Product 360 as well as tutorials on various topics. You will learn how to access and modify nearly all the data which is stored, including product, article and structure group information. We will explain the generic business model approach and how the persistence layer works.

Integrate with Product 360

Informatica MDM - Product 360 has a powerful REST Service API which can be used to integrate PIM data and logic into your own applications. The complete Service API is an official API of Product 360 and part of the maintenance.

Customize Product 360

The API documentation is provided as javadoc web pages which are in total available in the SDK build.

API

Java API

The Product 360 API has three levels of "stability":

Internal

Normal

All classes which are not contained in an internal package, but are not (yet) API. It's always a risk to use them, although not as much as for internal classes. Unheralded refacturings might be done by us in order to make them API in the future. However, we try to keep them stable as long as possible. Functional changes between hotfixes and service packs are very uncommon for those classes.

API

All classes, interfaces and methods which are marked as "API" will be held stable as long as possible. API classes are highlighted in this documentation.

Upgrade path:

API classes can be marked as deprecated a major or minor release, usually not in service packs or hotfixes. Deprecated classes will continue to work until the next major release. As usual in these cases we recommend to update your implementation as fast as possible Example: You use existing methods and classes which are marked as API in release 6.0. Then we define this api as deprecated for 6.5. The methods and classes will continue to work at least till the next major release which is 7.0.

Modification vs. Customizing

Product 360 customers should always be able to apply a service pack or a new release to the installation without breaking any product functionality or customizing added by the consulting partner team. Therefore no change to any part of the Product 360 source code is allowed. Additionally, every customizing in an installation should not use or rely on any interface or Java class, that is not clearly marked and documented as API. We know that sometimes there is no other possibility to do that, but in general, projects should try to avoid this. Anything that is not an API may change without any warning. Anything that is marked as API is documented and part of the product maintenance. If we do have an API change, the old interface will be available until we deprecate it in the next major release with an official statement.

Persistence Layer

The database layer, including JPA mappings and linked database plugins are not allowed to modify.

Domain Model / Repository

Adding own top entities which did not change the origin PIM entities is allowed. It's also allowed to add a Repository types section for that. Note that the 'links' to other PIM entities should modelled in your custom top entity types and not in the existing PIM entities. Our PIM Repository ist not marked generally as API. Please follow link to detailed description and especially what's allowed on 'Types' area and what's not.

API Request Process

Missing extension points, interfaces or API marked Java classes can be requested to be added to the API. This requires a detailed description why and how this extension point is needed, including an actual Customer Use-Case. After a positive review from Product Management and Development, this extension will be developed and shipped with an upcoming Service Pack. As an intermediate workaround it might be tolerable to use non-api classes for the special use case, but this has to be allowed by R&D.

Please contact your Global Customer Service representative and file an API request with them - they will help you through the process.