BOPF Special Associations - belsap.com

BOPF Special Associations

SAP AG, 2012

© 2012 SAP AG. All rights reserved. 2

Disclaimer

This presentation outlines our general product direction and should not be relied on in

making a purchase decision. This presentation is not subject to your license

agreement or any other agreement with SAP. SAP has no obligation to pursue any

course of business outlined in this presentation or to develop or release any

functionality mentioned in this presentation. This presentation and SAP's strategy and

possible future developments are subject to change and may be changed by SAP at

any time for any reason without notice. This document is provided without a warranty

of any kind, either express or implied, including but not limited to, the implied

warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP assumes no responsibility for errors or omissions in this document, except if

such damages were caused by SAP intentionally or grossly negligent.


Agenda

Introduction

Association Binding

Foreign Key Associations

Reverse Foreign Key Associations

Specialization Associations

Reverse Specialization Associations

Filtered Associations

Association Change Notifications

Cross-Business-Object Associations

Introduction


Association Type and Category

BOPF offers two different types of associations in the internal model.

Composite associations: From parent to child nodes

Categories:

Regular composition association

Specialization (not the same as “ specializations” from object orientation)

Association to delegated node (dependent object)

Framework associations (link to framework nodes)

General associations: Linked across the composition tree

Categories:

Foreign key association/reverse foreign key association

Reverse specialization

Association To_Parent

Association To_Root

Cross-BO association

Regular association (implementation-specific)


Association Configuration Cardinality and Resolving Node

Cardinality of an association: Number of node instances that are connected to

one source instance.

Resolving node: Associations can be distinguished according to the node that is

used to resolve the association.

Source-resolved associations

Source node contains information necessary for resolving the association

Target-resolved associations

Target node contains information necessary for resolving the association


Association Configuration Implementation vs. Binding

The association’s logic can be deposited in two different ways:

Implementation

Needed for associations with specific business logic not covered by existing association bindings

Implementation of the IF_FRW_ASSOCIATION interface necessary (not part of this training)

Example: Association that links hierarchically ordered items

Association binding

Can be modeled easily without any implementation work

Binding is resolved by the buffer implementation

Association types supported by binding: o Compositions (no binding necessary)

o Specialization/reverse specialization

o Foreign key associations/reverse foreign key associations

o To_Parent

o To_Root

o Cross-business-object associations

Recommendation: If possible, use association bindings to refine the BO model.

Association Binding


Foreign Key Association Example

KEY = 124

KEY = 123

Item Instances Buyer Instances

KEY = 789

REF_BUYER_KEY = 123

KEY = 632

REF_BUYER_KEY= 124

CUSTOMER_INVOICE Business Object

Foreign key associations are used if the source node of the association holds a

foreign key attribute of the association’s target node instance key.

Example: A customer invoice item instance contains a foreign key attribute called REF_BUYER_KEY identifying the buyer of this invoice using its KEY attribute.

Result of the association: IT_KEY = {789, 632} => ET_RESULT = {123,124}


Foreign Key Association Modeling

Select attribute containing the foreign

key values (must be RAW16 typed)

from the “Binding Patterns” button

Foreign key associations are

source-resolved

1

2

3

Only 1:0..1 or 1:1 cardinality

The binding is created

automatically afterwards.


Foreign Key Association Preconditions

Preconditions for selecting the foreign key association binding pattern:

Association cardinality must be always 1:1 or 1:0..1.

Association must be source-resolved (because the information of the target node instance

is located in the association’s source node).

Normal association category (not a composition)

Association’s source node must contain at least one RAW 16 typed attribute (to be the

foreign key). Only those attributes are shown in the submenu of the “Binding Pattern” button.

Creation of instances using a foreign key association only works if a composition

between source and target node exists in parallel. Otherwise, you must implement

the create method of that association.


Reverse Foreign Key Association Example

KEY =646

INVOICE_ID = 124

KEY= 789

INVOICE_ID = 456

Buyer Instance Item Instances

KEY = 456

KEY = 124

Reverse foreign key associations are used if the target node of the association

holds a foreign key of the source node instance key.

Example: A customer invoice buyer node instance contains a foreign key attribute called INVOICE_ID identifying the invoice’s instance KEY.

The association input IT_KEY := {456,124} produces the output of ET_TARGET_KEY

:= {789,646} .


Reverse Foreign Key Association Modeling

Select field containing

foreign key.

Reverse foreign key

associations are target-

resolved.

1

2

3


Reverse Foreign Key Association Preconditions

Preconditions for selecting the foreign key association binding pattern

Association must be target-resolved

Association category must be normal and it must not be a composition

The target node of the association must contain at least one RAW 16 typed attribute shown in the “Binding Patterns” button submenu. In addition, the KEY attribute and the ROOT_KEY

attribute (if the association source node is the ROOT node) of the target node are shown.

Creation of instances using a reverse foreign key association only works if a

composition between source and target node exists in parallel. Otherwise, you have

to implement the create method of that association.


Specialization Associations Definition

Specialization associations are similar to compositions (parent-child relationship) but they link only to child instances that fulfill a certain criterion.

This criterion is only related to the child instance attributes.

Example: The association only exists for instances of the “ Buyer” node that have the role GC_BUYER as value of attribute ROLE_CATEGORY.

A “ Normal” Composition A Specialization Association (with criterion ROLE_CATEGORY = GC_BUYER)

ROLE_CATEGORY

= GC_BUYER

ROLE_CATEGORY

= GC_SELLER

ROLE_CATEGORY

= GC_BUYER

ROLE_CATEGORY

= GC_SELLER

Root Instance

(Parent Node)

Party Instances

(Child Node)

Root Instance

(Parent Node)

Party Instances

(Child Node)


Specialization Associations Modeling

Select “ Specialization”.

2 Choose “ Constant Value”.

3 Select a constants interface.

1

2

3

Choose target-resolved.

1. Add new binding

4

4 Select constant

Automatically generated

binding


Specialization Associations Preconditions

Preconditions of the specialization pattern

A composition from the association’s source node to the target node must exist, but the

association itself must not be a composition.

The association category must be normal.

The association must be target-resolved.


Reverse Specialization Associations Definition

Reverse specialization associations are similar to To_Parent associations (child to

parent relationship), but they link only to target node instances for which the

association’s source instance attributes fulfill a certain criterion.

This criterion is only related to the association source instances.

Example: A normal To_Parent association leads from all children to their parent node instance. In the example, however, the association leads only from children whose attribute ROLE_CATEGORY is set to GC_BUYER to their corresponding parent instance.

“ Normal” To_Parent Association A Reverse Specialization Association (with criterion ROLE_CATEGORY = GC_BUYER)

ROLE_CATEGORY

= GC_BUYER

ROLE_CATEGORY

= GC_SELLER

ROLE_CATEGORY

= GC_BUYER

ROLE_CATEGORY

= GC_SELLER

Root Instance Party Instances Root Instance Party Instances


Reverse Specialization Associations Modeling

1

2

Typical use case for reverse specializations

Selective triggering of determinations: Instead of filtering irrelevant instances in the CHECK_DELTA() method of a determination, the association belonging to the request node can filter them out beforehand.

Select source-resolved.

2 Choose “ Constant Value”

3 Select a constants interface

1. Add new binding

4 Select constant


Reverse Specialization Associations Preconditions

Preconditions of the reverse specialization pattern

The association category must be normal.

The association cardinality must be 1:0..1 (it is 1:1 if there is a parent instance fulfilling the

condition and 1:0 if the parent instance does not fulfill the condition – thus only 1:0..1 is

allowed).

The association must be source-resolved.


Filtered Association Definition

If a filtered association is resolved (by the core service retrieve_by_association), a parameter can be passed from the consumer to select a subset of targets at runtime.

Filtered associations can be combined with other binding patterns.

Example: Only items that have a price higher than 5 euros are retrieved using this association.

PRICE = 4.99

Root Instance Item Instances

PRICE = 154.99

PRICE = 1.99

PRICE = 999.99

PRICE = 4.99

Association Parameter

PRICE > 5.00

Association Change Notifications


Association Change Notifications Overview

A

1

2

3

A

1

3

A

1

2

3

A

1

2

3

A:1,2,3 A:1,2,3 A: outdated A:1,3 Consumer

(Association Buffer)

BOPF

Consumer fills association buffer with the result of the retrieve_by_association of ROOT instance “ A” and its corresponding ITEM instances 1,2,3.

ITEM instance 2 is deleted by a modification delete call, thus the consumer’s buffer is outdated (but not aware of this). To inform the consumer , an association change notification is sent.

The consumer receives this association change notification and refreshes the buffer by calling retrieve_by_association again.


Association Change Notifications Creation

BOPF automatically detects (“ check&correct”) whether the manual creation of

association change notifications is needed or if the buffer/ framework is able to

create them.

Written by buffer

Written by BOPF

Written by implementation For some associations, it is necessary to manually create them using IO_MODIFY->NOTIFY_ASSOCIATION_CHANGE()

Cross-Business-Object

Associations


Cross Business Object Association Example

KEY = 124

KEY = 123

Root Instances Root Instances

KEY = 789

SALES_ORDER_REF=123

KEY = 632

SALES_ORDER_REF=124

Business Object CUSTOMER_INVOICE

A cross BO association can lead from any attribute of a source BO node to the key

attribute (or an unstructured alternative key) of the target BO node.

Example: In the invoice object a reference to the corresponding sales order is persistet.

Result of the association: IT_KEY = {789, 632} => ET_RESULT = {123,124}

Business Object SALES_ORDER


Creation of a Cross Business Object Association (1/2)

The source business object must be extended by a “Business Object Representation

Node”. BOPF automatically creates a Cross BO Association from the root node to that representation node. Further associations can be created manually.


Creation of a Cross Business Object Association (2/2)

1. Add new binding

2. Select “ Cross-BO

Binding” and press

Enter.

Choose 1:0..n or 1:1..n if the target node attribute is

not a unique alternative key or 1:1 or 1:0..1 if the

target node attribute is a unique alternative key.

Cross BO binding is always target-resolved

4. Select target node

attribute or alternative

key

3. Select source node

attribute

Further conditions, like constant binding, can be added.


Consumption of Cross Business Object Association

In order to resolve a cross business object association, always the service manager

of the source business object must be used (not io_read).

DATA lo_customer_invoice_sm TYPE REF TO /bobf/if_tra_service_manager.

DATA lt_customer_invoice_root_key TYPE /bobf/t_frw_key.

DATA lt_sales_order_root_data TYPE zti_t_root28.

" get the service manager of the source BO

lo_customer_invoice_sm = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = if_cust_invoice_c=>sc_bo_key ).

" get some instances of the customer invoice BO

lo_customer_invoice_sm->query(

EXPORTING

iv_query_key = if_cust_invoice_c=>sc_query-root-select_all

IMPORTING

et_key = lt_customer_invoice_root_key ).

" navigate the cross BO association

lo_customer_invoice_sm->retrieve_by_association(

EXPORTING

iv_node_key = if_cust_invoice_c=>sc_node-root

it_key = lt_customer_invoice_root_key

iv_association = if_cust_invoice_c=>sc_association-root-sales_order

iv_fill_data = abap_true

IMPORTING et_data = lt_sales_order_root_data ).


Cross-Business-Object Association

Preconditions

Preconditions of the cross-BO association binding:

To be able to add the association parameter binding category, the association must have an

association parameter.

The association must always be defined as target-resolved (by definition)

If the target node attribute cannot be a unique alternative key, ensure that the association

cardinality is either 1:1..n or 1:0..n. (This is necessary because an alternative key that is not

unique may produce more than one target instance for a single source instance.)

Hint: Cross-BO associations are never create-enabled.


Cross-Business-Object Association

Further Hints

Binding Pattern → Delete Pattern: Use this option to remove a binding pattern. This

ensures that the association category is set to regular again.

Use always the binding pattern because this sets the association’s category

automatically (exception: when adding additional association parameter filter

bindings or constant bindings).


Restrictions on the Association Binding

Or Why Implement Associations at All?

Additional restrictions (like constant binding or association parameter filtering) only

work when related to the source node (source-resolved associations) or target node

(target-resolved associations).

The KEY (RAW 16 typed) attribute always takes part of the binding either as a source

or target attribute. It is, for instance, not possible to bind between source attribute ISBN and target attribute ISBN_REF (this restriction is not relevant for cross-BO

bindings).

If the information needed to resolve an association is not located at the association’s

source node or at the target node, binding is not possible.

Thank you


© 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose

without the express permission of SAP AG. The information contained herein may be

changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary

software components of other software vendors.

Microsoft, Windows, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are

registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x,

System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power

Architecture, Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA,

pureScale, PowerPC, BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP,

RETAIN, DB2 Connect, RACF, Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli,

Informix, and Smarter Planet are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the United States and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered

trademarks of Adobe Systems Incorporated in the United States and other countries.

Oracle and Java are registered trademarks of Oracle and its affiliates.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin

are trademarks or registered trademarks of Citrix Systems Inc.

HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C®,

World Wide Web Consortium, Massachusetts Institute of Technology.

Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C,

Retina, Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc.

IOS is a registered trademark of Cisco Systems Inc.

RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry

Torch, BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App

World are trademarks or registered trademarks of Research in Motion Limited.

Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps,

Google Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync,

Google Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are

trademarks or registered trademarks of Google Inc.

INTERMEC is a registered trademark of Intermec Technologies Corporation.

Wi-Fi is a registered trademark of Wi-Fi Alliance.

Bluetooth is a registered trademark of Bluetooth SIG Inc.

Motorola is a registered trademark of Motorola Trademark Holdings LLC.

Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer,

StreamWork, SAP HANA, and other SAP products and services mentioned herein as well

as their respective logos are trademarks or registered trademarks of SAP AG in Germany

and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal

Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services

mentioned herein as well as their respective logos are trademarks or registered trademarks

of Business Objects Software Ltd. Business Objects is an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase

products and services mentioned herein as well as their respective logos are trademarks or

registered trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are registered trademarks

of Crossgate AG in Germany and other countries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks of their respective

companies. Data contained in this document serves informational purposes only. National

product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be

reproduced, copied, or transmitted in any form or for any purpose without the express prior

written permission of SAP AG.

BOPF Special Associations - belsap.com

Documents

Transcript of BOPF Special Associations - belsap.com