Custom fields in standard extractors –
making a mixed marriage work!
Prologue
SAP has done an excellent job in
providing standard extractors for most all data coming from R/3.
But, it can never match the collective ‘style='mso-bidi-font-style:normal'>ability’ of R/3 customers of creating
customized data models and enhancing standard R/3 functionality.
So, as SAP rolls out newer and
enhanced extraction components in successive releases of PI, often times the
developers find that their data fields are not available in standard
extractors. There was an excellent weblog on options regarding enhancing the
standard extractors sometime back. In this weblog series, I am going to explore
the ‘custom fields in standard extractors’ scenarios in detail.
Intent of this document is to
provide readers of a practical example and also list out the
constraints/pre-requisites when mixing custom fields with standard extractor
fields. Examples, wherever mentioned in this document refer to R/3 46C with PI
release 2002.1 and BW 3.0B.
Issues in detail
In an ideal scenario of pulling
data from R/3 to BW, we have standard extractors/data sources that fulfill the
business requirements. At times though we will have one (or more) custom field
(these can be standard SAP fields, but not available in standard extractor; for
sake of simplicity we will call all such fields as custom fields) that we need
to bring along with the standard extractor fields.
SAP gives us quite a few options to
realize this. The complexity lies in capturing the true ‘delta’ for such custom
fields, and in providing them ‘in order’ to BW. In the weblog by Roberto Negro
mentioned earlier above, these options are mentioned. I am going to walk
through an example of purchasing data (PO Item – 2LIS_02_ITM datasource) and
provide you the process followed in making this work.
Let us try to categorize different
scenarios (based on technical constraints of the underlying system)
Custom field available in extract structure enhancement
option (i.e. the field is part of the standard communication structure
underneath the extractor)
Custom field appended in extract structure and updated
using customer exit.
Custom field updated through standard LIS events (Using
LIS enhancements).
Custom field updated through other events not captured
by LIS.
style='mso-bidi-font-style:normal'>
Other options – Generic datasource/ODS combo, custom
delta mechanism
style='mso-bidi-font-style:normal'>
First of these is straightforward,
and I will straightaway jump to other scenarios. In this first part of weblog, I
will mostly be talking around what and how of the second scenario (enhancing
the extract structure by using APPEND).
In the second (and third) part of this weblog series, I will talk
about the remaining scenarios.
Enhancing the extract structure
In the latest release of PI, SAP
apparently doesn’t allow extending the extract structure. I am however going to
show a step-by-step process for doing this based on an earlier PI release, and
you may be able to do the same even on later PI.
Example scenario:
Customer has added an additional
field ‘Partner profit center’ to capture the contract manufacturer’s partner
profit center (note there is already a partner profit center in EKPO. This
custom field is added to EKPO table using standard purchasing exit MM06E005 and
is maintained using standard
font-family:PO
font-family: transactions (ME21N, 22N…).
Extract structure 2LIS_02_ITM is
extended (RSA6, option enhance extract structure). In the append structure
(Z*), I added field KOPPRCTR.
style='mso-bidi-font-weight:normal'>
Little pieces we forget that severely impact the
design……..
style='mso-bidi-font-weight:normal'>
Before talking of the steps
involved, let me dwell on the delta related issues. There are essentially two
categories of data we need to consider. One – when historical data is brought
over to BW using setup tables, and second – when delta updates are being
brought over to BW periodically. For the initial load, the code in user-exit
can assign values for this custom field relatively simply, however
complications arise in case of delta.
For 2LIS_02_ITM, there are two
records sent to communication structure for each change (Old, and new image).
The user-exit (or BADI) will need to assign correct values for the custom field
for each such record.
In our case, we store the custom
field data in a custom field in EKPO, hence we can do a ‘select’ on this table
to get the new data for our field and provide this to the extract structure.
However, how do we capture/determine the value before the change (before
image)? This is where the complexity comes in.
(You could have had the values for the custom field coming from some
other table or logic; the delta issue would still have been the same.)
Another distinction to remember is
that the user-exit runs when the extraction from BW is triggered, while the
delta might have happened much earlier (or worse, many times for the same
record since the last delta extraction). This means my logic in the user-exit
is fetching me the value of the custom field as it is at the time of
extraction, and not when the ‘delta’ (change via the application transaction
e.g. ME22N) happened. Also it means that the user-exit is executed only if
there is a delta captured (any of the standard communication structure fields
have changed).
style='mso-bidi-font-weight:normal'>
Back to our scenario….
To enable the delta functionality, we
need to capture the delta of the custom fields somewhere. We used change
document tables for this. (You can use some Z tables akin to BIW1 and BIW2
tables of LIS to capture delta of your custom fields).
style='mso-bidi-font-weight:normal'>
style='mso-bidi-font-weight:normal'>
Prerequisite:
Custom field must be based on a data
element that is change log enabled, and is part of a table which is included in
a change document object (or you can create a custom change document object).
The logic
