BSP in BW

[Former Member]

Hi girus

i have to create BSP application for Reporting in BW.can someone send me a sample programm.

i donot know anything about it please send me a valuable document or code if possible

my mail is.

maleffm@yahoo.de

regards,

Mangra

[Former Member]

Hi Mangra,

Heres an article which may help you,i read it somewhere:

Summary

It is quite remarkable to see how web technology has evolved. When I started using the Internet, approximately 10 years ago, I depended on a vt100 connection and a 4800 kbps modem with our provider. Browsing was purely textual with a lynx-type program. Then along came a connection to the CompuServe network, which was a big step forward thanks to its graphical interface. I said in an interview back at that time (1995) that the Internet wouldn't break through since there wasn't enough information and use for everybody. But who was I? Someone said the same thing later since he had something of his own, called "MSN." That seemed to be a mistake too. The browser war, Java applets, the Internet boom: We've seen them coming, and mostly going, fast - really fast. I won't show you any photos of the so-called personal computers from 1954 to prove my point.

Nowadays, the most complex web applications are available. All of our students can register, maintain their data, view their programs of study and schedules, etc., via the web. It's all possible.

By Eddy De Clercq

26 Dec 2004

The Need for Speed

All these applications produce management information, which needs to be processed in a particular manner. That's where SAP Business Information Warehouse fits in. A lot of advanced BW (web) reports are created for different domains, such as personnel and student administration. An example of student administration reporting is the number of students registered. As you might expect, this kind of report draws a lot of attention from a lot of people. So we need a solid, fast solution in order to provide accurate figures.

No Web Reports

For this particular project, we've chosen not to use web reports within BW. There are several reasons for this:

The load from the R/3 ERP info into InfoCubes takes a long time, so we can only load new data once a night.

The fact that the data itself is static means that the BW queries only need to run once. The figures won't change if you run the queries multiple times, it would only influence the performance of other possible queries.

The web interface capabilities of BW 3.0x are rather limited. Upgrading to BW 3.5 is in our planning for 2005.

No Documentation

One thing that I can say already - it wasn't easy. It's not that the coding itself is difficult as such, but a lack of proper documentation made it difficult to work out how to do it. Despite that, we discovered three possible ways to achieve our goal:

InfoSpokes is the newest technology. It's more geared towards direct raw access to InfoCubes and bulk exports though. So, it's no good for our query-based solution.

The FM WEBQUERY wraps HTML around the result. We want to create our own HTML.

The transaction RSCRM_BAPI is meant for scheduling queries. There are some caveats which make this solution unworkable for us. First of all, job names are generated at random, so one can't schedule jobs with job dependencies. Secondly, scheduling parameters are much less detailed than those which are used to in transaction SM37.

The solution for us was the FM RSCRMBW_REPORT. It does all the things we need. The only problem is the documentation, which is non-existent.

Now that we have a solution for our problem, let's look at the rest of what needs to be done. As I said, I presume that you have already done BW-related tasks, like creating InfoCubes, defining loads, queries, etc. If not, see your BW expert(s).

Step 1

Schedule your InfoCube loads.

Step 2

Create a report that calls the FM RSCRMBW_REPORT on your BW system.

CALL FUNCTION 'RSCRMBW_REPORT'

EXPORTING

i_mode = 'OPEN'

i_reportuid = name_query

• I_REPNAME =

• I_REPTXT =

• I_SAVE_AS = ' '

• I_OVERWRITE = ' '

I_PACKSIZE = 10000

I_EXECMODE = 'TABLE'

• I_FUNCNAME =

• I_DESTINATION =

I_EXTRACT = result_table

• I_PATH =

• I_REPEAT = ' '

• I_USER = SY-UNAME

• I_LANGU = SY-LANGU

I_SPLIT = ' '

• I_SEPARATOR = ';'

• I_BATCH_DATE =

• I_BATCH_TIME =

• I_BATCHID =

• I_UNIQUECHECK =

I_CLEAREXTRACT = 'X'

• I_CHECK_MEMBERS = 'X'

• I_USE_OLAP =

• I_REPAIR_VIEW = ' '

• I_NO_BATCH =

• I_VIEWID =

• I_GET_TEXTS = ' '

• I_GET_CMP_VALUES = ' '

• IMPORTING

• E_REPORTUID =

• E_BATCHID =

• E_CUBENAME =

• E_DONE =

• E_JOBNAME =

• E_JOBCOUNT =

TABLES

• E_T_AXIS =

• E_T_CELL =

• E_T_COUNT =

E_T_RETURN = it_return

• E_T_MDX =

• E_T_AXIS_V2 =

• E_T_CELL_V2 =

• E_T_MEMVAL_V2 =

As you can, see there are many configurable parameters, but no available documentation. We had to look at the code in order to know which parameters are the minimum requirements.

They are:

i_mode: The FM has several operational modes. First, you need to "initialise" everything with OPEN, and then it needs to run a second time with START. SO DON'T FORGET: the FM needs to be called TWICE with the same parameters (except for this one).

i_reportuid: The name of the query.

i_packsize: Setting the size packaging by character. It seemed to influence the transaction RSCRM_BAPI (see also note 739776), so we've also set it in here.

i_execmode: We want a table as result.

i_extract: The name of the result table.

i_split: Data-splitter.

i_clearextract: Delete content before new extract.

e_t_return: Result codes.

As previously mentioned, the FM needs to be called twice. So it might be a good idea to loop over these FMs if you have several queries to run.

Step 3

Schedule this report (transaction sm37) and let it wait until the load of InfoCubes job is terminated. Another option is to put this report as a step after the load in the same job.

Step 4

This depends a bit on how your data is managed and how your queries are defined. If you did a lot of normalization and used a lot of keys, you might need to write another report that joins you data with the description table(s). You can opt to do these joins in the query report. I like to keep them apart for testing purposes. Sometimes I only need to run the queries or vice versa.

Step 5

Schedule this report (transaction sm37) and let it wait until the query run job is terminated. Another option is to put this report as a step in the job after the load a query run.

Step 6

You may also need to create a backup mechanism that enables you to easily go to an older version if needed.

Step 7

So we now have as a result some tables on the BW system that can easily be retrieved. Write some remote enabled FM(s) to read these tables.

The BSP Application Itself

Step 1

Write the BSP that calls the FM(s) on the BW servers and wrap some layout around it.

Step 2

Test the whole bunch.

Conclusion

This method isn't comparable with OLAP, but is ideally suited to "static" data. The data only changes overnight, so there is no need to spend CPU time that other applications might need. The result can be seen at: http://www.kuleuven.ac.be/studinfo.

thanks,

ashish.