 |
What is MDR? |
| |
MDR stands for Mass Data Reporting.
Time and time again our consultants have been faced
with having to performance tune custom ABAP developments
for numerous implementations.
There is only so far even the most experienced developer
can go to improve the run-time of some custom reports
that deal with massive amounts of data. Unless of
course, they think parallel processing! This is
what MDR provides.
MDR is a frame-work that guides even the least experienced
developer to develop their custom programs in a
way such that when they are executed, they can utilize
as much of the expensive SAP hardware as you can
spare. Imagine literally cutting a program run-time
to 1/100th of the original run-time. That means
that those reports can be run in a matter of hours
rather than days, or minutes rather than hours.
MDR also provides a place to administer the execution
of these programs. To schedule programs at appropriate
times, to stop programs during peak times, and to
spread the load when necessary. MDR also gives your
business users a central place to view the report
results in what ever formats necessary. |
| |
^
top |
|
Is
there a need for MDR when we have Business Warehouse? |
| |
Some of our MDR clients also have
BW implementations. Although both Business Warehouse
and MDR are used to speed up, and make reporting
more flexible for your SAP system, their purpose
in a complete reporting strategy is complementary.
The use of Business Warehouse in an organization
is heavily centered around analytical reporting.
Data from your SAP system is extracted to your BW
system periodically, enabling BW fast and efficient
reporting from a snap-shot of data. This considerably
reduces system load, increases the usability of
the data and centralizes reporting. SAP BW solutions
have become an ever-increasing solution for centralized
reporting.
MDR's role in an organization is specifically suited
to real-time operational reporting. Our customers
find MDR crucial in being able to make daily operational
decisions based on quick, streamlined, real-time
information. MDR gives the business complete drill
down ability on details of a report, for example
from the report output the user can action a work
order. Although MDR is widely known as an optimized
reporting utility, it is commonly used in speeding
up transactional processes - processes that actually
update your SAP data, or provide output for the
business to directly action - this is not possible
from BW reporting. MDR can even dramatically improve
standard SAP processes in certain circumstances.
BW and MDR work side by side for a complete, centralized
and performance focused reporting strategy. |
| |
^
top |
|
Can
you stop a custom MDR program from executing? |
| |
When you have executed an MDR program,
a program instance is created. MDR can run this
instance over as many batch processes as you have
configured on your SAP system. If for example, 9:00
arrives, and your call centre traffic sky-rockets,
then an administrator can simply stop or pause the
program instance.
Since the MDR program works by processing mutually
exclusive intervals of data, MDR can be stopped
almost immediately. The good part of this is that
when your system load is much lower, you can continue
the processing of your MDR program exactly where
it was paused.
This is how massive amounts of data should be processed
in your custom reports; quickly, effectively and
with ultimate flexibility. |
| |
^
top |
|
How
is it that programs written using MDR can run so
quickly? |
| |
Reports written using MDR can increase
performance ten fold, or even a hundred fold. Instead
of running a report from start to finish, MDR splits
up the report into intervals of work. MDR then executes
this work in as many processes as you tell it to,
each process working in parallel with the others
to process all intervals as quickly as possible.
Too often, a company’s SAP application servers
are not used to their full potential - especially
with custom reports. MDR can help you solve this
problem. |
| |
^
top |
|
How
does MDR combine all the results of the parallel
jobs? |
| |
Since MDR splits the processing of
custom reports to optimise their run-time, MDR also
needs to collate this information back together.
A ‘collation routine’ is developed to
do this logic. This is just another piece of ABAP
code that enables you to collect, collate or append
the data together again. |
| |
^
top |
|
How
do I view the results of the output from an MDR
report? |
| |
MDR comes standard with the ability
to notify you when a program has completed. Usually,
jobs are run at night time in the batch schedule.
When they complete, either back-end configuration
or run-time configuration allows you to send a SAP
Office document to one or more recipients, either
to an external email address or the SAP Inbox. A
link to the interactive results is provided from
the email. |
| |
^
top |
|
Can
I use the same technique of viewing reports for
non-MDR programs? |
| |
Yes. MDR has a separate job that
can be configured to send SAP Office documents to
users for non-MDR programs that have been scheduled
to run in the background. In this way - you can
standardise the manner in which reports are delivered
to end-users. |
| |
^
top |
|
Can
the system usage for MDR programs be distributed
more evenly or altered at run-time? |
| |
One of the key abilities of MDR is
for a system administrator to control the resource
usage of the SAP system. As an MDR program executes,
the administrator is able to increase or decrease
the number of parallel jobs that are used to run
the report. Hence, at times of low on-line system
usage, the number of jobs can be increased in order
to make the job run faster. At times of peak on-line
usage, the number of jobs can be decreased so on-line
performance is not impacted. |
| |
^
top |
|
Why
would I ever create more intervals than the number
of jobs executing in parallel? |
| |
If an MDR program runs with 100 jobs
in parallel and these 100 jobs start working on
100 intervals, then all of the work to be done will
execute together. In an ideal situation, the 100
intervals will represent similar amounts of processing,
hence each interval will finish at the same time.
In the real world, however, intervals are not evenly
distributed. Hence by having 100 jobs and 100 intervals
time will be wasted because when the smaller intervals
have completed, the job has nothing more to do,
so completes. By having (for example) 1000 intervals,
you provide more flexibility and greater control
in the execution of the report and less chance of
wasting run-time. |
| |
^
top |
|
What
is the purpose of the transformation component of
an MDR program? |
| |
The MDR architecture enables the
developer to separate the processing logic from
the presentation logic. This is done by having two
separate programs - (1) a main program for the processing
and (2) a transformation program for the presentation.
The purpose of the transformation program is to
simply retrieve the data that has already been calculated
and to display it. There are no limitations to how
the data can be presented. One major benefit of
having a separate transformation program is that
the report can be interactive.
Unlike usual background ABAP reports that output
to the spool, a user is able to interact with the
output of an MDR program. For example, this might
be the ability to provide sub-totals or drill-down
on particular lines to display further information.
Furthermore, a transformation program can have its
own selection screen. This can further restrict
the data that is displayed to the user. |
| |
^
top |
