How To Enable Delta Queries using Syclo Exchange ...a248.g.akamai.net/n/248/420835/df2c91eebf8fe4574134f8...How To... Enable Delta Queries using Syclo Exchange Framework and SAP NetWeaver

SAP How-to Guide

Mobility

SAP Mobile Platform

provided by SAP Mobile - Rapid Innovation Group

Applicable Releases:

SAP Mobile Platform 3.0

SAP NetWeaver Gateway 2.0/SP07

Fahmi Cheikhrouhou, Jirong Wang, Matthias Tebbe

Version 1.0

November 2013

How To... Enable Delta Queries using Syclo Exchange Framework and SAP NetWeaver Gateway

SAP How-to Guide

Mobility

SAP Mobile Platform

provided by SAP Mobile - Rapid Innovation Group

© Copyright 2013 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, and PowerPoint 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, System z9, z10, z9, iSeries,

pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390,

OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power

Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER,

OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS,

HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex,

MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and

Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other

countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either

trademarks or registered trademarks of Adobe Systems Incorporated in

the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

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.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used

under license for technology invented and implemented by Netscape.

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

BusinessObjects Explorer, StreamWork, 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.

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.

This document is a preliminary version and not subject to your license

agreement or any other agreement with SAP. This document contains

only intended strategies, developments, and functionalities of the SAP®

product and is not intended to be binding upon SAP to any particular

course of business, product strategy, and/or development. Please note

that this document is subject to change and may be changed by SAP at

any time without notice.

SAP assumes no responsibility for errors or omissions in this document.

SAP does not warrant the accuracy or completeness of the information,

text, graphics, links, or other items contained within this material. 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 shall have no liability for damages of any kind including without

limitation direct, special, indirect, or consequential damages that may

result from the use of these materials. This limitation shall not apply in

cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not

affected. SAP has no control over the information that you may access

through the use of hot links contained in these materials and does not

endorse your use of third-party Web pages nor provide any warranty

whatsoever relating to third-party Web pages.

SAP “How-to” Guides are intended to simplify the product implement-

tation. While specific product features and procedures typically are

explained in a practical business context, it is not implied that those

features and procedures are the only approach in solving a specific

business problem using SAP NetWeaver. Should you wish to receive

additional information, clarification or support, please refer to SAP

Consulting.

Any software coding and/or code lines / strings (“Code”) included in this

documentation are only examples and are not intended to be used in a

productive system environment. The Code is only intended better explain

and visualize the syntax and phrasing rules of certain coding. SAP does

not warrant the correctness and completeness of the Code given herein,

and SAP shall not be liable for errors or damages caused by the usage of

the Code, except if such damages were caused by SAP intentionally or

grossly negligent.

Disclaimer

Some components of this product are based on Java™. Any code change

in these components may cause unpredictable and severe malfunctions

and is therefore expressively prohibited, as is any decompilation of these

components.

Any Java™ Source Code delivered with this product is only to be used by

SAP’s Support Services and may not be modified or altered in any way.

Document History

Document Version Description

1.00 First official release of this guide

Typographic Conventions

Type Style Description

Example Text Words or characters quoted

from the screen. These

include field names, screen

titles, pushbuttons labels,

menu names, menu paths,

and menu options.

Cross-references to other

documentation

Example text Emphasized words or

phrases in body text, graphic

titles, and table titles

Example text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

Example text User entry texts. These are

words or characters that you

enter in the system exactly

as they appear in the

documentation.

<Example

text>

Variable user entry. Angle

brackets indicate that you

replace these words and

characters with appropriate

entries to make entries in the

system.

EXAMPLE TEXT Keys on the keyboard, for

example, F2 or ENTER.

Icons

Icon Description

Caution

Note or Important

Example

Recommendation or Tip

Table of Contents

1. Change Detection Background & Use Case ......................................................................... 1

1.1 Overview .......................................................................................................................... 1

1.2 Solution Summary ......................................................................................................... 2

2. Implementation Guideline .................................................................................................... 6

2.1 EFI Development ............................................................................................................ 6

2.2 Exchange Table Development ....................................................................................... 8

2.3 Lock Object Development ............................................................................................. 8

2.4 Exchange Handler Development................................................................................... 9

2.5 Exchange Object Configuration .................................................................................. 13

2.6 EFI Configuration ......................................................................................................... 16

3. Prerequisites ....................................................................................................................... 18

4. Implementation Example: Walkthrough ............................................................................ 18

4.1 Create a new exchange table. ..................................................................................... 18

4.2 Find the appropriate trigger location. ......................................................................... 18

4.3 Create the EFI include .................................................................................................. 19

4.4 Create Exchange Handler Class .................................................................................. 23

4.5 Connect the created objects in the configuration panel ........................................... 28

4.6 Test the application ..................................................................................................... 30

5. Consuming Deltas from Gateway ...................................................................................... 31

5.1 Standard Exchange Table ........................................................................................... 31

5.2 Extended Exchange Table ........................................................................................... 32

How To... Enable Delta Queries using Syclo Exchange Framework and SAP NetWeaver Gateway Enable

Delta Queries using Syclo Exchange Framework and SAP NW Gateway

November 2013 1

1. Change Detection Background & Use Case There are a number of different approaches available to detect changes made to business objects

and to implement a delta query to retrieve those changes. Given the needs various business

scenarios have, there cannot be one single, “standard” approach.

This How-To Guide describes one of the possible ways, and it is your choice to consider and

implement other approaches to meet your business needs.

1.1 Overview Change detection in SAP Business Suite systems is a complex topic. SAP systems data can

typically be grouped into three categories: customization/configuration data, master data, and

transactional data. There are different use cases on how, why and when data in each category can

be changed in a SAP system. There are different technologies available to allow detecting changes,

such as a change pointer database, user exit, BAdIs, Business Transaction Events and many

others. However there is not a unified and consistent approach on how change detection should be

carried out.

In the context of mobile applications, especially offline capable mobile applications, the ability to

detect data changes in the backend SAP system becomes critical. This is because for offline

capable mobile applications, a fat mobile client is used. All categories of data from backend SAP

systems are downloaded to the mobile client in order to support continuous usage of the

application in a completely disconnected mode. Data being downloaded to the mobile device can

be quite large, with the advance of the mobile technology. When the mobile application client

reconnects to the backend system, the mobile client needs to be synchronized with the backend

system in order to receive the latest information. A complete refresh of the mobile client is typically

not practical from the perspective of data volume, user experience and functionality. Instead, the

ability to perform incremental synchronization with the backend system is required. In order to

support incremental synchronization from mobile client, change detection support in the backend

system is mandatory.

Currently there are two approaches that might be considered for delta handling:

1) Using Syclo Agentry xChange Framework

2) Using Delta Request Log Component

These two approaches can mainly be differentiated as follows:

The first approach, which is based on Syclo Exchange framework and the focus of this guide,

is calculating deltas at modification time. The ABAP system is tracking relevant changes

when they occur. At request time, the deltas are already prepared and thus available. On the

one hand this approach requires more development. On the other hand it’s more scalable and

has an optimized overall performance.

The second approach is based on delta determination at request time based on hash values,

where the system compares old and new state to find out which records have been

changed/deleted. The implementation effort is rather small but it’s not optimizing the

performance of the backend - meaning the more records you have in the full collection, the

longer the response time is for the request.

Agentry xChange Framework

The xChange Framework, which is part of Agentry SAP Framework, takes advantage of the

different technologies available within SAP system today. It provides a unified and consistent

approach on how to implement change detection in the ABAP based AP Business Suite systems,

and it supports information consumers such as offline enabled Agentry metadata based mobile



November 2013 2

applications. Non-Agentry metadata based applications, such as OData based mobile applications

with delta time token support can also take advantage of the xChange Framework for delta

calculation.

The xChange Framework approach is the focus of this guide and the remaining sections provide a

detailed description of the xChange Framework components, an implementation guideline, and a

step-by-step walk through example of how to create a delta query implementation.

Delta Request Log

Using this approach, the SAP NetWeaver Gateway OData channel runtime API methods,

GET_ENTITYSET and GET_ENTITYSET_DELTA are implemented and enhanced to support delta

query functionality.

In GET_ENTITYSET, in addition to retrieving entity collection data as usual, the entity collection is

passed to method /IWBEP/CL_QUERY_RESULT_LOG-> CREATE_UPDATE_LOG_ENTRY_HASH to

enable delta query functionality. This method is the central method for the Delta Token

functionality. It calculates a hash value for each product and stores the hash values in two

application tables (/IWBEP/D_QRL_HDR and /IWBEP/D_QRL_ITM) so the entries can be later

checked for changes. The method will also return a delta token which needs to be exported and

returned to the client with the entity collection data.

The actual delta calculation takes place, at request time, in method GET_ENTITYSET_DELTA.

GET_ENTITYSET_DELTA is called by the client with the delta token it received from the previous

call to GET_ENTITYSET. In GET_ENTITYSET_DELTA, the entity collection data is again retrieved,

just like in GET_ENTITYSET. Also performed again is the call to method

/IWBEP/CL_QUERY_RESULT_LOG-> CREATE_UPDATE_LOG_ENTRY_HASH with the entity

collection data where a hash value is calculated again for each entity. Those hash values are then

compared with the hash values of the prior call (related to the same delta token ID) to determine

which values have changed in the meantime.

The method will return a new delta token which needs to be exported and sent back to the client.

The method will also return any entries that were changed or deleted.

That sums it up. Basically, the advantage of the Delta Request Log Component is that the

implementation effort is rather small and provides sufficient delta functionality. The disadvantage

of this option is that there can be a negative performance impact on the backend, especially for

large collections.

Please refer to the guide “How to Implement Basic Delta Query Support in SAP NetWeaver

Gateway” on the SAP Community Network (SCN) for a detailed treatment of this topic.

1.2 Solution Summary Agentry xChange Framework consists of the following key concepts:

Exchange Framework Implementation (EFI)

Exchange Handler

Exchange Table

Exchange Object

A high level diagram is shown below to illustrate the change detection approach with the Agentry

xChange Framework.

http://scn.sap.com/docs/DOC-47043

http://scn.sap.com/docs/DOC-47043



November 2013 3

Figure - 1

Assigned Exchange

Objects

SAP Program

Exchange Framework

EFI Plug-in

Exchange

Table

Database Tables for

Master or Transaction Data

Agentry SAP Framework Change Detection Concept

xChange Framework

Data Object

Before

Image

After

Image

Assigned Exchange

Objects

Invoke

Evaluation Rules

Exchange

Class Handler

Data object change in SAP is handled by a SAP update program. The SAP update program can

be in the form of a program, a function module, a class, or an ABAP routine etc.

EFI - EFI is always embedded as part of the SAP update program. EFI serves as a listening

agent of the standard SAP data update process. EFI is responsible for collecting and building

the before image & after image of the data object being changed. Before/After image of the

data object is being represented based on the relational data model of the data object, in the

form of tables or structures. EFI will also determine whether the data object is being created,

updated, or deleted. It will provide the information via the action flag with value 'I' - Insert, 'U' -

Update, or 'D' - Delete. EFI will then pass the before/after image of the data object, along with

the action flag to the Exchange Object. Actual change detection is performed by the Exchange

Object based on the logic and business rules defined for the Exchange Object.

Exchange Object - Exchange Object is responsible for executoing change detection business

rules defined for the relevant mobile scenario. Exchange Object is a logical configuration object

that includes both technical settings such as exchange handler, exchange table, lock object etc,

as well as change detection business rules for the mobile scenario. Exchange Object is defined

via the ConfigPanel tool of the Agentry SAP Framework. Exchange Object is always assigned to

a single mobile application.

Exchange Table - This is the SAP persistent database table where information identifying the

changed data is stored. Typically an exchange table uses a minimum standard structure which

captures only minimum information about the data object that has been changed, such as



November 2013 4

mobile application, object key, last changed timestamp, change action (Insert/Update/Delete),

user. For some situations, an extended form of the exchange table can also be used in order to

support additional performance or functionality requirement. The xChange Framework allows

the ability to extend the exchange table structure, as long as the minimum standard structure is

implemented. It is recommended that separate Exchange Tables are defined for different types

of SAP data object. The same Exchange Table is typically shared by multiple mobile

applications which require change detection information for the same SAP data objects. By

default, Last Changed Timestamp is captured in the exchange table using the SAP system time

zone.

The minimum standard structure for an exchange table is defined by structure

'/SYCLO/CORE_EXCHANGE_KEY_STR' (key field) and structure

'/SYCLO/CORE_EXCHANGE_SUB_STR'. The following table lists the fields required in a

standard exchange table.

Figure 2

Field Name Data Element Key Field?

MANDT MANDT Yes

OBJKEY /SYCLO/CORE_EXCH_OBJKEY_DTE Yes

MOBILE_APP /SYCLO/CORE_MOBILE_APP_DTE Yes

ACTION /SYCLO/CORE_EXCH_ACTION_DTE No (Yes, to

detect

deletion/versio

ning)

CHANGED_TS /SYCLO/CORE_CHANGEDTS_DTE No(Yes for

versioning)

CHANGED_BY /SYCLO/CORE_CHANGEDBY_DTE No

REC_STATUS /SYCLO/CORE_EXCH_RECSTATUS_DTE No

filterable properties

(Optional)

Note: You can define additional fields as primary key(s) if required. An example is to set the

CHANGED_TS as primary key in order to add every single change to the exchange table,

even if the changed objects already exist in the exchange table. This use case provides a

kind of versioning feature to the delta mechanism.

For a modification of a filterable property you need to add two records to the exchange

table:

Add one record with a D (delete) action using the properties of the before image. Add

another record with an I (insert) action using the properties of the after image. The select

(as mentioned later in the document) will only filter on CHANGED_TS and the filterable

properties to detect inserts, updates, and deletions.

Note: It’s strongly recommended to add custom fields if filtering on the exchange table is

required to improve the performance. In the OData context it’s often helpful to add one or



November 2013 5

more of the filterable properties of the entity type for which the exchange table is built in

order to enable filtering on those properties. In this case the field CHANGED_TS must be

part of the primary key so that the information, if a specific record has been moved out of a

client section range, can be determined out of the records versioned with the CHANGE_TS

time stamp.

Use secondary indexes where appropriate.

Exchange Handler - This is the technical ABAP Object class that contains the programming

logic to support the change detection capability. A standard exchange handler base class

'/SYCLO/CL_CORE_EX_HANDLER_BASE' is provided by the xChange Framework.

The base class can be used for generic change detection. The generic change detection has the

following behavior:

- For object with action flag 'I' - Insert, change detection returns Boolean value 'True'.

- For object with action flag 'D' - Delete, change detection returns Boolean value 'True'.

- For object with action flag 'U'- Update, all of the before/after image of the relational

data tables or structures will be checked for changes. Value changes to any individual

attribute of these tables or structures will cause change detection to return Boolean

value 'True'.

- If change detection has result of Boolean value 'True', exchange table will be updated.

You should create a new exchange handler by declaring a subclass of

'/SYCLO/CL_CORE_EX_HANDLER_BASE' in order to provide an added enhancement to the

standard generic change detection. A sub-classed exchange handler is a commonly used

practice, as it gives you the flexibility to implement more targeted change detection support.

Common use cases of using new exchange handler include:

- Refine the specific scope of before/after image detection that is supported. Scope is

limited to what the EFI will provide, but can be more restrictive if required. This is done

by redefining method 'GET_FIELD_SELECTOR_TABLES'. This enhancement also allows

you the ability to define individual field by field change detection options via

ConfigPanel settings that is not available in generic change detection.

- Define condition filters for change detection. Condition filters allow you to restrict the

change detection to a subset of the SAP data object. For example, an order category

condition filter can be defined for a work order exchange handler. This will allow the

xChange Framework to apply change detection logic to only maintenance work orders,

but not production orders, even though both share the same technical update program

in the SAP ERP system. This is done by redefining method 'GET_DATA_FILTER_LIST'.

Once declared, condition filters will be visible in ConfigPanel, and condition rules can be

defined to control how change detection should be performed based on data set value.

EFI/Exchange Object Assignment - By assigning an Exchange Object to an EFI, change

detection for the Exchange Object is activated. When a SAP data object is changed, EFI is

triggered. Each Exchange Object that is assigned to this EFI is invoked automatically. Same set

of Before/After image from EFI is provided to each Exchange Object for it to perform the

required change detection rules and logic. It is common when multiple applications use the

same SAP data object. Multiple Exchange Objects from different mobile applications are

assigned to the same EFI. It is also common to have multiple Exchange Objects configured in

the same mobile application and assigned to the same EFI. This allows the ability to define

different change detection rules for the same technical object but for different scenarios. For



November 2013 6

example, regular change detection for maintenance work order might use a different change

detection rule than emergency work order with push support.

2. Implementation Guideline

Prerequisites

In order to use this approach, it’s mandatory to have the Syclo foundation framework (SMFND

600_700) installed on the system. Please review the prerequisites listed in the Prerequisites

section of this guide.

2.1 EFI Development

EFI trigger spot determination

In order to determine the proper EFI trigger spot, the standard SAP data object update process

must be analyzed. A trigger spot can be identified and implemented in different ways: user exit,

BAdI implementation, explicit or implicit enhancement framework implementation, Business

Transaction Event etc. Given the key role of EFI to construct the before/after image data pair

list of the SAP data object being changed, the EFI trigger spot will determine to what extent and

scope change detection can be computed. If the complete before/after image data pair list can

be provided by the EFI, full change detection is possible. If only partial before/after image data

pair list is provided by EFI trigger, it will not be possible for Exchange Object to detect changes

for all possible data change variations. Sometimes it might also be necessary to have multiple

EFI trigger spots for the same SAP data object change in order to support comprehensive

change detection for the data object.

EFI Coding

Current xChange Framework Implementation requires that an ABAP include file is created. The

include file can contain the programming logic for before/after image construction. Use tcode

'SE38' to create the EFI include file.

Standard coding patterns have been established for EFI programming. The following pseudo-

code pattern can be used for any EFI programming. Section highlighted in green background

must be implemented for the specific EFI.

**********************************************************************

* Data Declaration Section

**********************************************************************

*OO Reference Variables

DATA: lref_exception TYPE REF TO cx_root.

*Tables & Structures

DATA: lt_efi_data TYPE /syclo/core_exch_chngdata_tab,

ls_efi_data LIKE LINE OF lt_efi_data.

*Variables

DATA: lv_efi_objkey TYPE /syclo/core_exch_objkey_dte,



November 2013 7

lv_efi_action TYPE /syclo/core_exch_action_dte,

lv_efi_active TYPE wdy_boolean.

*Constants

CONSTANTS: lc_efi_incl_name TYPE /syclo/core_efi_incl_dte VALUE 'xxxx',

lc_source_routine_name TYPE string VALUE 'yyyy'.

**********************************************************************

* Main Section

**********************************************************************

TRY.

/syclo/cl_core_exch_serv=>logtrace_exch_begin( iv_efi_include =

lc_efi_incl_name

iv_source = lc_source_routine_name ).

/syclo/cl_core_exch_serv=>get_exchange_active( lc_efi_incl_name ).

IF lv_efi_active = abap_true.

"Determine the proper EFI action.

"Insert: use value /syclo/cl_core_constants=>exch_action_insert

"Update: use value /syclo/cl_core_constants=>exch_action_update

"Delete: use value /syclo/cl_core_constants=>exch_action_delete

lv_efi_action = ???

"Log EFI action

/syclo/cl_core_exch_serv=>logtrace_exch_action_info( iv_action =

lv_efi_action

iv_source = lc_source_routine_name ).

"Determine the EFI object key

lv_efi_objkey = ???

"Build before/after image array

ls_efi_data-tabname = 'xxx'.

ls_efi_data-dref_new_data = ???

ls_efi_data-dref_old_data = ???

append ls_efi_data to lt_efi_data.

/syclo/cl_core_exch_serv=>update_exchange(

EXPORTING iv_objkey = lv_efi_objke

iv_efi_include = lc_efi_incl_name

iv_action = lv_efi_action

it_data = lt_efi_data ).

ENDIF.

CATCH cx_root INTO lref_syclo_exception.

/syclo/cl_core_appl_logger=>logger->catch_class_exception(

EXPORTING iref_exception = lref_exception ).



November 2013 8

ENDTRY.

2.2 Exchange Table Development

To define a standard exchange table, use tcode 'SE11' to create a transparent table in the data

dictionary. Include the standard structures '/SYCLO/CORE_EXCHANGE_KEY_STR' and

'/SYCLO/CORE_EXCHANGE_SUB_STR'. Set structure

'/SYCLO/CORE_EXCHANGE_KEY_STR' as key.

To define an exchange table with an extended structure, in addition to the minimum standard

structure for exchange table, add additional fields for the exchange table. For example, an

extended exchange table with the additional fields of 'WERKS' and 'LGORT' in the following

example.

For extended exchange tables, exchange handler method 'SAVE_EXCHANGE_TABLE' should

be redefined in order to update the additional attributes.

Exchange table is not intended to be a history table. Its table contents should be purged

regularly. Standard purge program '/SYCLO/CORE_EXCH_PURGE_PROG' is provided to

purge exchange tables. A background job to run the purge program periodically is

recommended. The number of days of change history that should be maintained in an

exchange table is controlled by Exchange Object setting, see below.

For optimal runtime performance, a secondary index is recommended when defining a new

exchange table.

2.3 Lock Object Development

Define a lock object for exchange table using tcode 'SE11'. Lock table is necessary to provide

the necessary lock mechanism during update process for the exchange table. Lock object info

can be defined in Exchange Object definition. If defined, it is checked when exchange table is

being updated.



November 2013 9



November 2013 10

2.4 Exchange Handler Development Exchange handler contains the program code that will execute the change detection logic algorithm

based on the before/after image provided by EFI trigger.

Create custom exchange handler.

Use tcode 'SE24' to create a subclass handler using base class

'/SYCLO/CL_CORE_EX_HANDLER_BASE'.

Refine method ' GET_FIELD_SELECTOR_TABLES' of the exchange handler, to declare a list of

data pairs the exchange handler will be able to support.

The declared data pair list can be the full list of before/after image provided by EFI triggers, or it

can be a subset. Any data pair declared by exchange handler but not provided by the EFI

trigger will be ignored. Data pair name defined in field '/SYCLO/CORE-

EX_FLDSEL_SERV_STR-TABNAME' should match the value defined in EFI trigger before/after

image data pair list, and it should be a valid DDIC table name or structure name. See the

example code below on how to declare the data pair. Both table 'BUT000' and 'BUT050' are

declared by the sample code. Section highlighted in green background should be changed for

your specific exchange handler and data object.

**********************************************************************


**********************************************************************


DATA: lt_field_selector_tables TYPE /syclo/core_ex_fldsel_serv_tab.

*Field Symbols

FIELD-SYMBOLS: <selector_table> TYPE LINE OF /syclo/core_ex_fldsel_serv_tab.

**********************************************************************

* Main Section

**********************************************************************

REFRESH et_fldsel_table_list.

APPEND INITIAL LINE TO lt_field_selector_tables ASSIGNING <selector_table>.

<selector_table>-ex_handler = me->clsname.

<selector_table>-tabname = 'BUT000'.



November 2013 11

APPEND INITIAL LINE TO lt_field_selector_tables ASSIGNING <selector_table>.

<selector_table>-ex_handler = me->clsname.

<selector_table>-tabname = 'BUT050'.

et_fldsel_table_list = lt_field_selector_tables.

The declared data pair list will be displayed on the ConfigPanel. With data pair list declared,

individual table field level change detection settings can be defined via ConfigPanel. In the

following screen shot, table 'BUT000' and table 'BUT050' are displayed.

Redefine method ' GET_DATA_FILTER_LIST' of the exchange handler, to declare a list of change

condition filters the exchange handler will support.

A change condition filter requires a reference table/structure name and field name. The

reference table/structure name should be one of the data pairs declared by method

'GET_FIELD_SELECTOR_TABLES'. If not, it will be ignored. Once the filters are declared, change

condition rules can be defined in ConfigPanel. The condition rules will be evaluated as part of the

change detection process. If the data object being evaluated does not fulfill the change

conditions, the change condition process will be skipped, and the boolean value 'FALSE' is

returned.



November 2013 12

The standard evaluation algorithm is supported by the base exchange handler

'/SYCLO/CL_CORE_EX_HANDLER_BASE', method 'PROCESS_FILTER'. It applies an 'ALL or

Nothing' algorithm. If a condition filter rule is defined for a line item table, all records for the data

object line item table must fulfill the condition rule. If an 'ANY or Nothing' algorithm is required

for line item level filters, you will need to redefine the method 'PROCESS_FILTER' with your own

program code.

In the following code example, two condition filters are declared: filter 'BU_TYPE' for table

'BUT000' field 'TYPE', and filter 'ROLE_TYPE' for table 'BUT100' field 'RLTYP'. Section

highlighted in green background should be changed for your specific exchange handler and data

object.


DATA:

lt_data_filter TYPE /syclo/core_ex_filter_serv_tab.

*Field Symbols

FIELD-SYMBOLS:

<data_filter> TYPE LINE OF /syclo/core_ex_filter_serv_tab.

**********************************************************************

* Main Section

**********************************************************************

REFRESH et_data_filters.

*Field Filter for exchange object

APPEND INITIAL LINE TO lt_data_filter ASSIGNING <data_filter>.

<data_filter>-ex_handler = me->clsname.

<data_filter>-dof_name = 'BU_TYPE'.

<data_filter>-usage_tabname = 'BUT000'.

<data_filter>-usage_fieldname = 'TYPE'.

APPEND INITIAL LINE TO lt_data_filter ASSIGNING <data_filter>.

<data_filter>-ex_handler = me->clsname.

<data_filter>-dof_name = 'ROLE_TYPE'.

<data_filter>-usage_tabname = 'BUT100'.

<data_filter>-usage_fieldname = 'RLTYP'.

et_data_filters = lt_data_filter.

Redefine method 'GET_DATA_FILTER_VALUESET'' of the exchange handler, to provide a

predefined value list for specific condition filters.

Condition filters with a pre-defined value list are displayed as a drop-down list of fields on the

ConfigPanel. For condition filter which references a table field that has a domain value check list

defined in DDIC, it is automatically shown as a dropdown list.

In the following code example, a specific value set for filter 'ROLE_TYPE' is constructed by the

program logic. There is already DDIC check value list for the reference table field 'TYPE' of table

'BUT000'. Both condition filters are displayed as a dropdown list on the ConfgPanel. The



November 2013 13

section highlighted by green background should be changed for your specific exchange handler

and data object.

**********************************************************************


**********************************************************************


DATA: lt_filter_valset TYPE /syclo/core_ex_fltsrv_vset_tab.

**********************************************************************

* Main Section

**********************************************************************

REFRESH et_filter_valset.

* Business Partner Types

CLEAR: lt_filter_valset.

/syclo/cl_crmcore_valset_tools=>get_crm_bupa_roletype_valset(

EXPORTING iv_ex_handler = me->clsname

iv_do_mthd = 'GET'

iv_dof_name = 'ROLE_TYPE'

IMPORTING et_ex_valset = lt_filter_valset ).

APPEND LINES OF lt_filter_valset TO et_filter_valset.

SORT et_filter_valset BY ex_handler dof_name value.

ConfigPanel shows a dropdown list for both declared condition filters.



November 2013 14

Redefine method ' PROCESS_FILTER' of the exchange handler, if you need to overwrite the

standard condition filter rule evaluation algorithm.

For example this might be the case when you have declared line item level condition filters and

need to implement logic to support 'ANY or Nothing' condition filter rules logic.

Redefine method ' SAVE_EXCHANGE_TABLE' of the exchange handler, if you need to overwrite

the standard update logic for exchange table.

For example this might be the case when you have an extended exchange table structure,

which includes additional non-standard attributes in the exchange table that need to be

populated.

Implement method ' PROCESS_SYNC_LINKAGE' of the exchange handler, if linkage processing

is going to be supported by the exchange handler.

2.5 Exchange Object Configuration Exchange Object is a customization object that combines technical objects such as exchange class

handler, exchange table, and lock object with configuration rules. It allows you to control the

runtime change detection behavior by defining specific customizing rules for different mobile

scenario use cases. Change detection functionality defined by each Exchange Object is limited to

what the underlying technical objects (exchange class handler, exchange table) can support.

To create an exchange object, use ConfigPanel (IMG Agentry SAP Framework Configuration

Exchange Process Settings Define Exchange Object Settings). Important attributes include



November 2013 15

Exchange Object ID, description, mobile application, application area, exchange table name,

exchange handler, and lock object. Use the 'Active Flag' to control whether the exchange object is

enabled. Use 'Days To Keep History' to control the archive/purge setting for exchange table

content.

Based on the exchange handler selected, the Change Detection Field Selection tab shows a list of

tables/structures for which individual field level change detection can be supported. In the example

below, change detection only applies to value change for field MC_NAME1 and MC_NAME2 of the

Business Partner General Data 1 table 'BUT000'.



November 2013 16

Based on the exchange handler selected, the Change Detection Condition Filter tab shows list of

condition filters supported. You can define condition filter rules in range table format. Use 'Active

Flag' of Rule Editor area to enable/disable a rule. Use 'Ignore Data Creation', 'Ignore Data Deletion',

and 'Ignore Data Update' to control whether change detection should be restricted to a specific

data change process (Create/Update/Delete).



November 2013 17

2.6 EFI Configuration Configuration for an EFI trigger allows you to assign exchange objects to a specific EFI trigger. To

create a new EFI setting, use ConfigPanel (IMG Agentry SAP Framework Configuration

Exchange Process Settings Define Enhancement Implementation Include (EFI) Settings).

EFI trigger is identified in ConfigPanel by the EFI Include File. For each EFI trigger, a number of

exchange objects can be assigned. This is typical because multiple mobile applications can share

the same SAP data object and requires change detection support.

It is also possible to define different exchange objects to support different change detection rules

for multiple use cases within the same mobile app. For example, an exchange object used to

initiate a push process might have a different change detection rule than regular change detection

scenario. A separate push relevant exchange object can be defined to support this.



November 2013 18

EFI Include File must exist in the SAP system.

Multiple exchange objects can be assigned to the same EFI trigger. Use 'Active Flag' to enable/disable an assignment.



November 2013 19

3. Prerequisites In order to use this approach, it’s mandatory to have the following software components installed

on the system, including the Syclo foundation framework:

SAP Mobile Platform 3.0

SAP NetWeaver Gateway 2.0, SP07 (IW_BEP 200 SP07)

Syclo Agentry SAP Framework Integration Foundation (SMFND 600_700)

Requires minimum SAP NetWeaver 7.00, BASIS SP14

Please note that the Syclo foundation framework is part of the SAP Mobile Platform

3.0

Additional Information:

Note 1921547 - How to integrate OData service with standard exchange table

4. Implementation Example: Walkthrough The following implementation shows an example where the Syclo foundation framework is used to

implement Delta calculation for contacts. It describes a minimum set to get changes added to an

exchange table whenever a CRM contact (Business partner) gets modified, inserted or deleted.

In this example an extended exchange table is used. This is because we want to track changes on

contacts but we want also to save the account IDs to which the changed contact belongs.

This has the advantage that, later on when we request for changed contacts, we can directly filter

on account and retrieve the relevant modified contacts only.

4.1 Create a new exchange table. Create a transparent table (ZCHF_CONTP_EX) in the data dictionary with the following

fields/include structures:

Field MANDT, Data element MANDT

Include Syclo Standard Structures /SYCLO/CORE_EXCHANGE_KEY_STR

Include Syclo Standard Structure /SYCLO/CORE_EXCHANGE_SUB_STR.

Set structure /SYCLO/CORE_EXCHANGE_KEY_STR as key.

Field ACCOUNTID (Data Element BU_PARTNER).

Data class: APPL0

Size category: e.g.: 3

Enhancement category: e.g. Cannot be enhanced.

Since our exchange table has an additional filed, it’s called an extended exchange table.

4.2 Find the appropriate trigger location. For our example we use the BAdI PARTNER_UPDATE to catch any changes: In the SE80 go to

package BUPA and expand Enhancements Classic BAdI’s (def.)

Select PARTNER_UPDATE and from the menu Implementation select Create. In this example the

BAdI implementation has the name ZCHF_SYCLO_BP_UPD.

Implement method CHANGE_BEFORE_UPDATE. In that implementation just call a new EFI include

that we will create in the next step using forward navigation:

https://service.sap.com/sap/support/notes/1921547



November 2013 20

METHOD if_ex_partner_update~change_before_update.

INCLUDE zchf_efi_contact_incl.

ENDMETHOD.

4.3 Create the EFI include As described in the beginning of this document, the purpose of the EFI is to collect the changes and

pass them to the Syclo framework.

Create Custom Business Partner Type

We need to create a structure and table type that the EFI implementation code uses below.

Go to transaction SE11 and enter Data type name “ZCHF_SYCLO_BUPA_ID_TAB” and select the

Create button.

In the subsequent prompt, select option “Table type” and select Continue (or press <Enter>).

Enter a description for the Short text (e.g. “Business Partner IDs”) and for Line Type, enter name

“ZCHF_SYCLO_BUPA_ID_STR”.

Double click on the name of the Line Type just entered and select “Yes” when prompted to create

the type and “Yes” when prompted to save before exiting editing.

Enter an appropriate Package and continue. This time select “Structure” when prompted.

Provide a short description and fill in the Component as shown below.

Proceed to menu item Extras Enhancement Category…

Select option “Can be enhanced (character-type or numeric)” and select the Copy button.

Save and Activate. Make sure to select the item for table type “ZCHF_SYCLO_BUPA_ID_TAB”

during activation also.



November 2013 21

Implement EFI Include

Double click the name of the EFI include we just entered in the BAdI-implementation to create a

new include.

Important note: All processing steps within the EFI include must be inside a try-catch block to

intercept any runtime exception which might occur because of any erroneous custom code!

In this example all that we need to do is to determine the contact details before and after the

update. Note that this example does not track all changes. Extend it by checking the other business

partner related tables if required.

*&---------------------------------------------------------------------*

*& Include ZCHF_EFI_CONTACT_INCL

*&---------------------------------------------------------------------*

DATA:

lref_syclo_contact_exception TYPE REF TO cx_root,

* Table that willbe passed to the syclo framework

lt_syclo_contact_data TYPE /syclo/core_exch_chngdata_tab,

* Key of changed object)

lv_syclo_objkey TYPE /syclo/core_exch_objkey_dte,

* Action

lv_syclo_action TYPE /syclo/core_exch_action_dte,

lv_syclo_active TYPE wdy_boolean,

lv_source TYPE string,

* before and after image tables

lt_but000_old TYPE STANDARD TABLE OF but000,

lt_but000_new TYPE STANDARD TABLE OF but000,

lt_curr_but000_old TYPE STANDARD TABLE OF but000,

lt_curr_but000_new TYPE STANDARD TABLE OF but000,



lt_curr_but020_old TYPE STANDARD TABLE OF but020,

lt_curr_but020_new TYPE STANDARD TABLE OF but020,

lt_contacts TYPE zchf_syclo_bupa_id_tab.

CONSTANTS:

lc_syclo_efi_incl TYPE /syclo/core_efi_incl_dte VALUE 'ZCHF_EFI_CONTACT_INCL',

lc_tabname_but000 TYPE tabname16 VALUE 'BUT000',

lc_tabname_but020 TYPE tabname16 VALUE 'BUT020'.

FIELD-SYMBOLS:

<ls_but000> TYPE but000,


<ls_contact> TYPE zchf_syclo_bupa_id_str,

<ls_syclo_contact_data> LIKE LINE OF lt_syclo_contact_data.

TRY.

lv_source = /syclo/cl_core_mdo_tools=>get_routine_name( iv_depth = 2 ).



November 2013 22

CONCATENATE 'Class' lv_source INTO lv_source SEPARATED BY space.

/syclo/cl_core_exch_serv=>logtrace_exch_begin( iv_efi_include = lc_syclo_efi_incl

iv_source = lv_source ).

lv_syclo_active = /syclo/cl_core_exch_serv=>get_exchange_active( lc_syclo_efi_incl ).

IF lv_syclo_active = abap_true.

* Get the updated Business Partner Data

CALL FUNCTION 'BUPA_GENERAL_CALLBACK'

TABLES

et_but000_old = lt_but000_old

et_but000_new = lt_but000_new

EXCEPTIONS

OTHERS = 0.

* Get the updated Address

CALL FUNCTION 'BUPA_ADDR_CALLBACK'

TABLES

et_but020_old = lt_but020_old

et_but020_new = lt_but020_new.

LOOP AT lt_but000_new ASSIGNING <ls_but000> WHERE type = 1. "contacts (persons) only!

APPEND INITIAL LINE TO lt_contacts ASSIGNING <ls_contact>.

<ls_contact>-partner = <ls_but000>-partner.

ENDLOOP.

IF sy-subrc <> 0.

LOOP AT lt_but020_new ASSIGNING <ls_but020>.



ENDLOOP.

LOOP AT lt_but020_old ASSIGNING <ls_but020>.



ENDLOOP.

* Remove blanks and duplicates.

SORT lt_contacts BY partner.

DELETE lt_contacts WHERE partner IS INITIAL.

DELETE ADJACENT DUPLICATES FROM lt_contacts COMPARING partner.

* Get before/after affected BUT000 since callback returned nothing.

IF lt_contacts IS NOT INITIAL.

SELECT * FROM but000 INTO TABLE lt_but000_old FOR ALL ENTRIES IN lt_contacts WHERE p

artner = lt_contacts-partner.

lt_but000_new = lt_but000_old.

ENDIF.

ENDIF.

SORT: lt_but000_old BY partner.



November 2013 23

SORT: lt_but000_new BY partner.

SORT: lt_but020_old BY partner.

SORT: lt_but020_new BY partner.

LOOP AT lt_contacts ASSIGNING <ls_contact>.

"Key

lv_syclo_objkey = <ls_contact>-partner.

"Get Insert/Update action

READ TABLE lt_but000_old WITH KEY partner = <ls_contact>-

partner TRANSPORTING NO FIELDS.

IF sy-subrc <> 0.

lv_syclo_action = /syclo/cl_core_constants=>exch_action_insert.

ELSE.

lv_syclo_action = /syclo/cl_core_constants=>exch_action_update.

ENDIF.

"Action set to

/syclo/cl_core_exch_serv=>logtrace_exch_action_info( iv_action = lv_syclo_action


"Object key set to

/syclo/cl_core_exch_serv=>logtrace_exch_objkey_info( iv_objkey = lv_syclo_objkey


CLEAR: lt_curr_but000_old, lt_curr_but000_new, lt_curr_but020_old, lt_curr_but020_new

.

* BUT000

APPEND INITIAL LINE TO lt_syclo_contact_data ASSIGNING <ls_syclo_contact_data>.

<ls_syclo_contact_data>-tabname = lc_tabname_but000.

APPEND LINES OF lt_but000_old TO lt_curr_but000_old.

APPEND LINES OF lt_but000_new TO lt_curr_but000_new.

DELETE lt_curr_but000_old WHERE partner <> <ls_contact>-partner.

DELETE lt_curr_but000_new WHERE partner <> <ls_contact>-partner.

GET REFERENCE OF lt_curr_but000_old INTO <ls_syclo_contact_data>-dref_old_data.

GET REFERENCE OF lt_curr_but000_new INTO <ls_syclo_contact_data>-dref_new_data.

* BUT020

APPEND INITIAL LINE TO lt_syclo_contact_data ASSIGNING <ls_syclo_contact_data>.

<ls_syclo_contact_data>-tabname = lc_tabname_but020.

APPEND LINES OF lt_but020_old TO lt_curr_but020_old.

APPEND LINES OF lt_but020_new TO lt_curr_but020_new.

DELETE lt_curr_but020_old WHERE partner <> <ls_contact>-partner.

DELETE lt_curr_but020_new WHERE partner <> <ls_contact>-partner.

GET REFERENCE OF lt_curr_but020_old INTO <ls_syclo_contact_data>-dref_old_data.

GET REFERENCE OF lt_curr_but020_new INTO <ls_syclo_contact_data>-dref_new_data.

/syclo/cl_core_exch_serv=>update_exchange( EXPORTING iv_objkey = lv_syclo_objkey

iv_efi_include = lc_syclo_efi_in

cl



November 2013 24

iv_action = lv_syclo_action

it_data = lt_syclo_contac

t_data ).

ENDLOOP.

ENDIF.

CATCH cx_root INTO lref_syclo_contact_exception. "#EC CATCH_ALL

/syclo/cl_core_appl_logger=>logger->catch_class_exception(

EXPORTING iref_exception = lref_syclo_contact_exception ).

ENDTRY.

4.4 Create Exchange Handler Class This step is about creating the class that is responsible for filtering deltas and adding them to the

corresponding exchange tables.

Create a class (ZCHF_CL_CONTACT_EX_HDL) that inherits from the Syclo super class

/SYCLO/CL_CORE_EX_HANDLER_BASE. Since we are using a so called extended exchange table

where we have an additional field, we need to redefine the method SAVE_EXCHANGE_TABLE in

order to be able to fill them.

The following provides sample code for SAVE_EXCHANGE_TABLE that determines how to fill the

ACCOUNTID field based on the existing relationships.

method SAVE_EXCHANGE_TABLE.

* Sample implementation for the redefined method save_exchange_table

* allowing us to save more details into the exchange table...

CONSTANTS :

lc_bur001 TYPE bu_reltyp VALUE 'BUR001' .

DATA:

lref_typedescr TYPE REF TO cl_abap_typedescr,

lref_structdescr TYPE REF TO cl_abap_structdescr,

lref_structdescr_exch TYPE REF TO cl_abap_structdescr,

lref_exception TYPE REF TO cx_root,

ls_exch_data TYPE zchf_contp_ex, "your exchange table

ls_exch_raw_data TYPE /syclo/core_exchtab_data_str,

lv_extended_tab TYPE /syclo/core_boolean_dte,


lref_data TYPE REF TO data,



lt_relationships TYPE TABLE OF bapibus1006_relations,

lt_return TYPE bapirettab.

FIELD-SYMBOLS:

<input_data> TYPE any,

<input_data_x> TYPE x,

<component> TYPE abap_compdescr,

<ls_data> LIKE LINE OF it_data,

<lt_but000> LIKE lt_but000_new,




November 2013 25

<lt_but050> LIKE lt_but050_new,


<lt_but050_old> LIKE lt_but050_old,

<ls_but050_old> TYPE but050,

<ls_relationships> LIKE LINE OF lt_relationships.

CLEAR: me->message.

ev_error = abap_true.

me->message = 'Entering method ~ SAVE_EXCHANGE_TABLE...'(m18).

me->logger->logtrace( iv_message = me->message

iv_source = me->source ).

IF me->str_exchobj_setting-skip_update = abap_true.

CLEAR ev_error.

RETURN.

ENDIF.

TRY.

ASSIGN iref_data->* TO <input_data> .

MOVE-CORRESPONDING <input_data> TO ls_exch_data.

READ TABLE it_data ASSIGNING <ls_data> WITH KEY tabname = 'BUT000'.

IF sy-subrc EQ 0.

ASSIGN <ls_data>-dref_new_data->* TO <lt_but000>.

ENDIF.


IF sy-subrc EQ 0.

ASSIGN <ls_data>-dref_new_data->* TO <lt_but050>.

ENDIF.

IF <lt_but000> IS NOT INITIAL.

SORT <lt_but000> BY partner.

ENDIF.

READ TABLE <lt_but000> ASSIGNING <ls_but000> WITH KEY partner = iv_objkey

BINARY SEARCH.

IF ( <lt_but050> IS NOT ASSIGNED OR <lt_but050> IS INITIAL ) AND <ls_but000>-

type = '2' .

"Nothing to do: we are handling contacts only and there are any relationship changes!

CLEAR ev_error.

RETURN.

ENDIF.

IF <ls_but000>-type = '1' AND ( <lt_but050> IS NOT ASSIGNED OR <lt_but050> IS INITIAL ).

CALL FUNCTION 'BAPI_BUPA_RELATIONSHIPS_GET'

EXPORTING

businesspartner = <ls_but000>-partner

TABLES

relationships = lt_relationships



November 2013 26

return = lt_return.

DELETE lt_relationships WHERE relationshipcategory NE lc_bur001

OR validuntildate < sy-datum OR validfromdate > sy-datum.

IF lt_relationships IS INITIAL.

CALL METHOD me->add_extended_record

EXPORTING

is_exch_data = ls_exch_data.

ELSE.

LOOP AT lt_relationships ASSIGNING <ls_relationships> WHERE partner2 = iv_objkey .

ls_exch_data-accountid = <ls_relationships>-partner1.


EXPORTING


ENDLOOP.

" Get deleted contact relationship


IF sy-subrc = 0.

ASSIGN <ls_data>-dref_old_data->* TO <lt_but050_old>.

LOOP AT <lt_but050_old> ASSIGNING <ls_but050_old> WHERE partner2 = iv_objkey .

ls_exch_data-accountid = <ls_but050_old>-partner1.

ls_exch_data-action = 'D'.


EXPORTING


ENDLOOP.

ENDIF.

ENDIF.

ENDIF.

IF <ls_but000>-type = '1' AND <lt_but050> IS ASSIGNED AND <lt_but050> IS NOT INITIAL.

LOOP AT <lt_but050> ASSIGNING <ls_but050>.

ls_exch_data-accountid = <ls_but050>-partner1.


EXPORTING


ENDLOOP.

ENDIF.

IF <ls_but000>-type = '2' AND <lt_but050> IS ASSIGNED AND <lt_but050> IS NOT INITIAL.

ls_exch_data-accountid = iv_objkey.

LOOP AT <lt_but050> ASSIGNING <ls_but050>.

ls_exch_data-objkey = <ls_but050>-partner2.


EXPORTING


ENDLOOP.

ENDIF.

CLEAR ev_error.



November 2013 27

CATCH cx_root INTO lref_exception.

me->logger->catch_class_exception(

iv_source = me->source

iref_exception = lref_exception ).

RETURN.

ENDTRY.

endmethod.

Create and Implement Method to Add Extended Record

Add a new method that will add the extended record to the exchange table.

In the class definition for class “ZCHF_CL_CONTACT_EX_HDL”, in the Methods tab, add a new

method called “ADD_EXTENDED_RECORD” as shown below.

Select the Parameter button and add an Importing parameter “IS_EXCH_DATA” with Associated

Type “ZCHF_CONTP_EX”.



November 2013 28

Click on the Methods button to go back and double click on the ADD_EXTENDED_RECORD method

to implement it with the following code.

method ADD_EXTENDED_RECORD.

DATA:

lt_data TYPE /syclo/core_exch_chngdata_tab,

ls_exch_raw_data TYPE /syclo/core_exchtab_data_str,

lref_data TYPE REF TO data.

FIELD-SYMBOLS: <input_data> TYPE any,

<input_data_x> TYPE x,

<component> TYPE abap_compdescr,

<ls_data> LIKE LINE OF lt_data.

GET REFERENCE OF is_exch_data INTO lref_data.

ASSIGN lref_data->* TO <input_data_x> CASTING.

IF sy-subrc <> 0.

RETURN.

ENDIF.

" Get the Exchange table

ls_exch_raw_data-exch_tabname = me->str_exchobj_setting-exch_tabname.

ls_exch_raw_data-data = <input_data_x>.

IF me->update_task = space.

me->message = 'Calling FuncMod /SYCLO/CORE_EXCH_BIN_DATA_SAVE ...'(i17).



CALL FUNCTION '/SYCLO/CORE_EXCH_BIN_DATA_SAVE'

EXPORTING

is_exch_data = ls_exch_raw_data.

IF sy-subrc <> 0.

RETURN.

ENDIF.

ELSE.

me->message = 'Calling FuncMod /SYCLO/CORE_EXCH_BIN_DATA_SAVE in UPDATE TASK...'(i18).




November 2013 29


CALL FUNCTION '/SYCLO/CORE_EXCH_BIN_DATA_SAVE' IN UPDATE TASK

EXPORTING

is_exch_data = ls_exch_raw_data.

ENDIF.

endmethod.



November 2013 30

4.5 Connect the created objects in the configuration panel Go to the configuration panel (TA /SYCLO/CONFIGPANEL) and create the following objects:

Mobile application:

Select Mobile Application Configuration and create a new Mobile Application:

Exchange object

Go back to the to the start page using the ConfigPanel Home link and select Exchange Object

configuration. Click the button Create to create a new exchange object.



November 2013 31

EFI assignment

Go back to the start page and select EFI Assignment. Click the button Create to create a new

assignment:



November 2013 32

4.6 Test the application Start transaction BP to change a contact (person). In our case we will change the contact with the

Business partner ID 94:

Now go to the exchange table and –if everything is done correctly- you should see an entry for this

change in the exchange table.



November 2013 33

5. Consuming Deltas from Gateway This section describes how you can leverage the exchange table processing into an OData service

implemented in SAP Netweaver Gateway.

5.1 Standard Exchange Table The helper class /SMFND/CL_CORE_EXOBJ_TOOLS can be used to access exchange tables.

Implement SAP Note 1860943 in case this class is not defined on the system. Note that the current

version of this implementation doesn’t support the usage of filtering. This is the case where the

exchange table contains custom fields and the caller wants to retrieve deltas by filtering on one or

more custom fields.

Return Delta Token

In GET_ENTITYSET, after normal entity set processing, create a delta token and return it in the

response. Following creates a basic delta token based on the current timestamp.

DATA: lv_delta_token TYPE timestamp.

...

" Usual GET_ENTITYSET Code

...

* Calculate delta token based on timestamp

GET TIME STAMP FIELD lv_delta_token.

* Export the delta token

es_response_context-deltatoken = lv_delta_token.

As a result, a delta token link will be returned at the end of the response for the entity collection.

Get Deltas

When a request for an entity collection that includes a delta token is sent to Gateway, the

GET_ENTITYSET_DELTA method for that collection is called. So this is where the code to retrieve

deltas should be implemented. The following provides a simple example to retrieve deltas from an

exchange table using the helper class /SMFND/CL_CORE_EXOBJ_TOOLS.

...

" Get Delta token from request…

lo_delta_context ?= io_tech_request_context.

lv_delta_token = lo_delta_context->get_deltatoken( ).

" SYCLO BRIDGE

" get deltas from corresponding exchange table in case a delta token is provided.

IF lv_delta_token IS INITIAL.

" A token should have been passed. If not, an exception can be thrown here.

...

ELSE.

"----------------------------------------"

http://service.sap.com/sap/support/notes/1860943



November 2013 34

" DELTA MODE

"----------------------------------------"

MOVE lv_delta_token TO lv_ts.

CALL METHOD /smfnd/cl_core_exobj_tools=>determine_delta_objkeys

EXPORTING

iv_mobile_app = 'ZCHF_MOBILE_APPLICATION'

iv_exchobj = 'ZCHF_CONTACT_EXCHANGE_OBJECT'

iv_time_token = lv_ts

iv_time_zone = 'UTC'

IMPORTING

eref_exch_data = lr_ref_exch_data

* eref_formatted_keylist =

eref_objkey_list_range = lr_ref_objkey_list_range

* ev_last_changed_ts =

.

IF lr_ref_exch_data IS NOT INITIAL.

ASSIGN lr_ref_exch_data->* TO <lt_delta_tab>.

" Inspect exchange table data.

" Handle deleted case (e.g. where action = 'D'). Add to ER_DELETED_ENTITYSET.

...

" Handle insert/update (e.g. where action = 'I' or 'U'). Add to ER_ENTITYSET

ENDIF.

* Export new delta token

GET TIME STAMP FIELD lv_delta_token.

es_response_context-deltatoken = lv_delta_token.

ENDIF.

5.2 Extended Exchange Table The current implementation of the helper class doesn’t support filtering on additional fields yet. In

case filtering is required, implement your own method to retrieve the data from the Syclo table. In

the following, a very simple example of such an implementation is provided. This is to be done in

the GET_ENTITYSET_DELTA method.

...

READ TABLE it_filter_select_options INTO ls_filter_select_options WITH KEY prop

erty = 'ACCOUNTID'.

DATA: BEGIN OF ls_delta,

changed_ts TYPE zchf_contp_ex-changed_ts,

objkey TYPE zchf_contp_ex-objkey,

action TYPE zchf_contp_ex-action,

END OF ls_delta,



November 2013 35

lv_last_objkey TYPE zchf_contp_ex-objkey,

lt_entityset_deleted LIKE et_entityset.

SELECT MAX( changed_ts ) objkey action FROM zchf_contp_ex INTO ls_delta

WHERE changed_ts > lv_timestamp AND

accountid IN ls_filter_select_options-select_options

GROUP BY objkey action

ORDER BY objkey changed_ts DESCENDING action DESCENDING.

IF lv_last_objkey = ls_delta-objkey.

CONTINUE.

ENDIF.

IF ls_delta-action = 'D'.

" handle deleted case (e.g add to ER_DELETED_ENTITYSET of method get_entity

set_delta

ELSE. " U / I

" handle inserted and updated case

" 1. move objkey to the key structure for structured keys

" 2. read required details from the business application eg. using a BAPI

ENDIF.

"Remember the last record to avoid deleted and changed records returned in th

e same response

lv_last_objkey = ls_delta-objkey.

ENDSELECT.

...

http://scn.sap.com/community/mobile

http://developers.sap.com/mobile

http://www.sap.com/smp

Documents

How To Enable Delta Queries using Syclo Exchange ...a248.g.akamai.net/n/248/420835/df2c91eebf8fe4574134f8...How To... Enable Delta Queries using Syclo Exchange Framework and SAP NetWeaver