Information object intended use

[Lauri Arra]

Hello community! Just wanted to post a question to hear your thoughts on something where I think I know the answer, but the outcome is still bugging me.

How exactly are information objects supposed to be related to Business Applications? Yes, I've read the documentation, but let's walk through a real example:

Let's say we have information object named 'Employee data' and on the SAP HR business app we create the first relationship to this object and note that SAP HR can read, write, create, and delete the data.
Next, we create a digital interface record under SAP HR and relate the information object to that digital interface. We then create a digital integration between this digital interface and Azure Active Directory - the idea being that Azure reads the employee data from SAP HR and creates the user objects.

What happens now? Should I create a relationship from Azure Active Directory and only assign 'read' operation for this relationship? As Azure creates its own user database, should I also create a new Information Object to identify this? Alternatively, should I only have one Information Object for employee data and use relationships to link it to every business application that is interacting with employee data and also every database catalog that is physically storing the data?

[Hendrik-Engler · Accepted solution]

Hi @Lauri Arra,

maybe following helps: An Information Objects represent the logical business information, not its technical implementations; hence you usually do not create multiple Information Objects (IO) describing the same data. Then you can pair this IO set with the Digital Interfaces (define how the IO flows in/out of an application) and the Digital Integrations (define how the data are exchanged between interfaces).

SAP HR ifor example s the system of record (SoR) for your employee data; therefore it should have Create, Read, Update, Delete (CRUD) permissions, so this is correctly filed on the IO mapped to your business application. Now you could define a digital interface for SAP HR which for example supports Read / Write operations and is related to the IO for employee data.

As Azure consumes the data (e.g. to create user accounts) you can also define the IO on the BA level and for example define the Read operation.

You now link both together via a digital integration, defining provider / subscriber BA information along the provider interface on SAP side being used for example and also map the IO here as the data are exhanged.

So overall you are already on the right track.

[Bruno De Graeve]

https://www.servicenow.com/docs/bundle/zurich-application-portfolio-management/page/product/applicat...