15 Jul 2009

Scheduling Process Chain multiple times a day using Events

On high level, following are the Steps
1)Create an event Eg : 'Z_REDCOP_DAILY_LOAD_CHAIN_EVENT'
2)Create a Program to call the FM : BW_EVENT_RAISE by passing event id like below ( we used Z_BW_EVENT_RAISE here )
3)Create a Job at frequency of 2 hours.( in SM36 ).In the step information of the job specify the above program created
4)Specify the eventid in the process chain start variant also.

Explanation : Step 1
a) Goto Sm62.
b) Open last tab
c) Click on Creat button and give technical name/desc of the event.


Explanation : Step 2
REPORT ZBW_EVENT_TRIGGER_PROGRAM.
DATA : EVENTID LIKE TBTCO-EVENTID.
DATA : DATE TYPE SY-DATUM.

DATE = SY-DATUM.
IF DATE+06(02) LE 16.
EVENTID = 'Z_REDCOP_DAILY_LOAD_CHAIN_EVENT'.

CALL FUNCTION 'Z_BW_EVENT_RAISE'
EXPORTING
EVENTID = EVENTID
EXCEPTIONS
BAD_EVENTID = 1
EVENTID_DOES_NOT_EXIST = 2
EVENTID_MISSING = 3
RAISE_FAILED = 4
BP_EVENT_RAISE_OTHERS = 5
OTHERS = 6
.
IF SY-SUBRC <> 0.
ENDIF.

ENDIF.

Explanation : Step 3
a) Open Sm36.
b) Give Job name and target system. Save

c) If it asks for ABAP program then give our program name ( if notClick on STEP button and it will ask ). Give variants if necessary.

d) Click save. It shows :

e) Now go back to main screen and click on start condition and give 2 hours periodic setting there.
f) Save.
g) Check in Sm37 if job is scheduled….


Explanation : Step 4

Specify the eventid in your Start variant of the process Chain.

30 May 2009

Calculation on data which is split into different packages

During the data load data is split by data packets and the start routine in update rule is applied packet by packet. It is hence not possible to do calculation in start routine which requires a group of the records as they
could be split in to different packets.

Solution1 :
In reference to the blog
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/3f91f628-0b01-0010-9da8-9e7ca2cbb104

we have mark the infopackage to load the data only upto to PSA.Then we extract data of PSA , apply our logic for calculation and write back to PSA. After we can update data from PSA to data targets.
That is,
The ABAP for reading the PSA data and writing back to PSA is in four sections
a- Get the request number ( call FM : RSSM_API_REQUEST_GET )
b- Get data ( call FM : RSAR_ODS_API_GET )
c- Change Data ( Custom code to do the calculations that you want )
d- Write data back to PSA ( Call FM : RSAR_ODS_API_PUT )

Solution2:
If your loading data from and ODS to any data target. Then we follow this approach.
You can write a custom program to update the active table of the source ODS.
As active table is a flat table, you can easily do your calculations using a custom program and update the active table. Following is the program i tried for my requirment :

REPORT ZBW_SORTING_HR.

DATA: IT_RESULTS LIKE /BIC/AZPT_O0200 OCCURS 0 WITH HEADER LINE.
DATA: WA_TEMP LIKE /BIC/AZPT_O0200.
DATA: IT_SORTED1 LIKE /BIC/AZPT_O0200 OCCURS 0 WITH HEADER LINE.
DATA: KEY3(255) TYPE C,KEY1(255) TYPE C, KEY2(255) TYPE C.
DATA: END_DATE LIKE /BIC/AZPT_O0200-calday.
DATA: START_DATE LIKE /BIC/AZPT_O0200-calday.
clear : it_results.

SELECT * FROM /BIC/AZPT_O0200 INTO TABLE IT_RESULTS.

SORT it_results by
EMPLOYEE
CALDAY
REPTT
UNIT.

clear : wa_temp,it_sorted1.
clear : key1,key2,start_date,end_date.

LOOP AT IT_RESULTS INTO WA_TEMP.

CONCATENATE WA_TEMP-EMPLOYEE WA_TEMP-REPTT INTO KEY1.

IF KEY2 = KEY1.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.
ELSE.
START_DATE = WA_TEMP-CALDAY.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.

ENDIF.

KEY2 = KEY1.

APPEND WA_TEMP TO IT_SORTED1.
endloop.

UPDATE /BIC/AZPT_O0200 FROM TABLE IT_SORTED1.

20 May 2009

Templates for Start Routine

Following is the sample code for start routine in Transformation :

DATA: WA_TEMP TYPE DATA_PACKAGE_STRUCTURE, KEY1(255) TYPE C, KEY2(255)
TYPE C.
DATA: KEY3(255) TYPE C.
DATA: END_DATE LIKE DATA_PACKAGE-CALDAY.
DATA: START_DATE LIKE DATA_PACKAGE-CALDAY.

SORT DATA_PACKAGE BY
EMPLOYEE
CALDAY
REPTT
UNIT.

LOOP at DATA_PACKAGE INTO WA_TEMP.

CONCATENATE WA_TEMP-EMPLOYEE WA_TEMP-REPTT INTO KEY1.

IF KEY2 = KEY1.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.
ELSE.
START_DATE = WA_TEMP-CALDAY.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.

ENDIF.


KEY2 = KEY1.

MODIFY DATA_PACKAGE FROM WA_TEMP.

ENDLOOP.

18 Mar 2009

Dynamic table name in select statement in ABAP

Here is a sample code piece used :

DATA name_snp_chn(20) TYPE c VALUE '/bic/azmmiv_sc00'.
DATA name_snp_usa(20) TYPE c VALUE '/bic/azmmiv_sU00'.
DATA name_snp_eur(20) TYPE c VALUE '/bic/azmmiv_sE00'.
DATA name_snp(20) TYPE c VALUE '/bic/azmmiv_os00'.

DATA name_mov_chn(20) TYPE c VALUE '/bic/azmmiv_2c00'.
DATA name_mov_usa(20) TYPE c VALUE '/bic/azmmiv_2U00'.
DATA name_mov_eur(20) TYPE c VALUE '/bic/azmmiv_2E00'.
DATA name_mov(20) TYPE c VALUE '/bic/azmmiv_o200'.

DATA : BEGIN OF ITAB OCCURS 0,
FACALID LIKE /BI0/MPLANT-FACTCAL_ID,
END OF ITAB.

if I_ZREGION = 'CHN'.
name_snp = name_snp_chn.
name_mov = name_mov_chn.
elseif I_ZREGION = 'USA'.
name_snp = name_snp_usa.
name_mov = name_mov_usa.
elseif I_ZREGION = 'EUR'.
name_snp = name_snp_eur.
name_mov = name_mov_eur.
endif.



IF i_test = 'X'.
BREAK-POINT.
* xl_plant = 'AA'.
* xl_stor_loc = '7000'.
* xl_material = '000000000000010712'.

xl_plant = 'RYAN'.
xl_stor_loc = '7000'.
xl_material = '000000000007519620'.

* xl_plant = 'CL00'.


SELECT * FROM (name_snp)
INTO CORRESPONDING FIELDS OF TABLE io_snapshot
WHERE plant EQ xl_plant
AND stor_loc EQ xl_stor_loc
AND material EQ xl_material.
ENDIF.

17 Mar 2009

Where to check for code used in extractor of DS

Goto to RSA2 in source system.
Give the datasource.
Check the extractor details. Click on the extractor. It will open the code.

3 Mar 2009

Idocs between R3 and BW while extraction

1)When BW executes an infopackage for data extraction the BW system sends a Request IDoc ( RSRQST ) to the ALE inbox of the source system.Information bundled in Request IDoc (RSRQST) is :
Request Id ( REQUEST )
Request Date ( REQDATE )
Request Time (REQTIME)
Info-source (ISOURCE)
Update mode (UPDMODE )
2)The source system acknowledges the receipt of this IDoc by sending an Info IDoc (RSINFO) back to BW system.The status is 0 if it is ok or 5 for a failure.
3)Once the source system receives the request IDoc successfully, it processes it according to the information in the request. This request starts the extraction process in the source system (typically a batch job with a naming convention that begins with BI_REQ).
The request IDoc status now becomes 53 (application document posted). This status means the system cannot process the IDoc further
4)The source system confirms the start of the extraction job by the source system to BW by sending another info IDoc (RSINFO) with status = 1
5)Transactional Remote Function Calls (tRFCs) extract and transfer the data to BW in data packages. Another info IDoc (RSINFO) with status = 2 sends information to BW about the data package number and number of records transferred
6)At the conclusion of the data extraction process (i.e., when all the data records are extracted and transferred to BW), an info IDoc (RSINFO) with status = 9 is sent to BW, which confirms the extraction process.

18 Feb 2009

Appearence of Values for charecterstic input help screen

Which settings can I make for the input help and where can I maintain these settings?
In general, the following settings are relevant and can be made for the input help for characteristics:

Display: Determines the display of the characteristic values with the following options "Key", "Text", "Key and text" and "Text and key".
Text type: If there are different text types (short, medium and long text), this determines which text type is to be used to display the text.
Attributes: You can determine for the input help which attributes of the characteristic are displayed initially. When you have a large number of attributes for the characteristic, it makes sense to display only a selected number of attributes. You can also determine the display sequence of the attributes.
F4 read mode: Determines in which mode the input help obtains its characteristic values. This includes the modes "Values from the master data table (M)", "Values from the InfoProvider (D)" and "Values from the Query Navigation (Q)".
Note that you can set a read mode, on the one hand, for the input help for query execution (for example, in the BEx Analyzer or in the BEX Web) and, on the other hand, for the input help for the query definition (in the BEx Query Designer).


You can make these settings in InfoObject maintenance using transaction RSD1 in the context of the characteristic itself, in the InfoProvider-specific characteristic settings using transaction RSDCUBE in the context of the characteristic within an InfoProvider or in the BEx Query Designer in the context of the characteristic within a query. Note that not all the settings can be maintained in all the contexts. The following table shows where certain settings can be made:

Setting RSD1 RSDCUBE BExQueryDesigner
Display X X X
Text type X X X
Attributes X - -
Read mode
- Query execution X X X
- Query definition X - -


Note that the respective input helps in the BEx Web as well as in the BEx Tools enable you to make these settings again after executing the input help.

When do I use the settings from InfoObject maintenance (transaction RSD1) for the characteristic for the input help?
The settings that are made in InfoObject maintenance are active in the context of the characteristic and may be overwritten at higher levels if required. At present, the InfoProvider-specific settings and the BEx Query Designer belong to the higher levels. If the characteristic settings are not explicitly overwritten in the higher levels, the characteristic settings from InfoObject maintenance are active.

When do I use the settings from the InfoProvider-specific characteristic settings (transaction RSDCUBE) for the input help?
You can make InfoProvider-specific characteristic settings in transaction RSDCUBE -> context menu for a characteristic -> InfoProvider-specific properties.
These settings for the characteristic are active in the context of the characteristic within an InfoProvider and may be overwritten in higher levels if required. At present, only the BEx Query Designer belongs to the higher levels. If the characteristic settings are not explicitly overwritten in the higher levels and settings are made in the InfoProvider-specific settings, these are then active. Note that the settings are thus overwritten in InfoObject maintenance.

When do I use the settings in the BEx Query Designer for characteristics for the input help?
In the BEx Query Designer, you can make the input help-relevant settings when you go to the tab pages "Display" and "Advanced" in the "Properties" area for the characteristic if this is selected.
These settings for the characteristic are active in the context of the characteristic within a query and cannot be overwritten in higher levels at present. If the settings are not made explicitly, the settings that are made in the lower levels take effect.

How can I display attributes for the characteristic in the input help?
Attributes for the characteristic can be displayed in the respective filter dialogs in the BEx Java Web or in the BEx Tools using the settings dialogs for the characteristic. Refer to the related application documentation for more details.
In addition, you can determine the initial visibility and the display sequence of the attributes in InfoObject maintenance on the tab page "Attributes" -> "Detail" -> column "Sequence F4". Attributes marked with "0" are not displayed initially in the input help.

Why do the settings for the input help from the BEx Query Designer and from the InfoProvider-specific characteristic settings not take effect on the variable screen?
On the variable screen, you use input helps for selecting characteristic values for variables that are based on characteristics. Since variables from different queries and from potentially different InfoProviders can be merged on the variable screen, you cannot clearly determine which settings should be used from the different queries or InfoProviders. For this reason, you can use only the settings on the variable screen that were made in InfoObject maintenance.

Why do the read mode settings for the characteristic and the provider-specific read mode settings not take effect during the execution of a query in the BEx Analyzer?
The query read mode settings always take effect in the BEx Analyzer during the execution of a query. If no setting was made in the BEx Query Designer, then default read mode Q (query) is used.

How can I change settings for the input help on the variable screen in the BEx Java Web?
In the BEx Java Web, at present, you can make settings for the input help only using InfoObject maintenance. You can no longer change these settings subsequently on the variable screen.

15 Jan 2009

ABAP program to find prev request in cube and delete

There will be cases when we cannot use the SAP built-in settings to delete previous request..The logic to determine previous request may be so customised, a requirement.
In such cases you can write a ABAP program which calculates previous request basing our own defined logic.
Following are the tables used :
RSICCONT ---(list of all requests in any particular cube)
RSSELDONE ----- ( has got Reqnumb, source , target , selection infoobject , selections ..etc)
Following is one example code. Logic is to select request based on selection conditions used in the infopackage:
REPORT ZGET_LAST_REQ_SHORT_RUN.
PARAMETERS : TAR_CUBE(9) TYPE C,
SOUR_ODS(9) TYPE C.
DATA : IT_REQ LIKE TABLE OF RSICCONT.
data : it_REQ_WA type RSICCONT.
DATA : IT_CALMONTH_LOW TYPE /BI0/OICALMONTH.
DATA : IT_CALMONTH_HIGH TYPE /BI0/OICALMONTH.
data : diff type N.
DATA : IT_REQ_CUBE LIKE TABLE OF RSSELDONE.
data : it_REQ_CUBE_WA type RSSELDONE.
data : sour_tar(22) type C.
TABLES : ZBW_PARAM.
CLEAR It_REQ.
CLEAR it_REQ_WA.
CLEAR it_REQ_CUBE.
CLEAR DIFF.
concatenate SOUR_ODS '_TO_' TAR_CUBE INTO SOUR_TAR.
SELECT * FROM RSICCONT INTO TABLE IT_REQ WHERE ICUBE = TAR_CUBE.
LOOP AT IT_REQ INTO IT_REQ_WA.
SELECT * FROM RSSELDONE INTO TABLE IT_REQ_CUBE WHERE RNR = IT_REQ_WA-RNR AND SOURCE = SOUR_ODS AND FIELDNAME = 'CALMONTH'.
ENDLOOP.
LOOP AT IT_req_cube into it_req_cube_wa.
IT_CALMONTH_LOW = IT_REQ_CUBE_wa-LOW.
IT_CALMONTH_HIGH = IT_REQ_CUBE_wa-HIGH.
diff = IT_CALMONTH_HIGH - IT_CALMONTH_LOW.
if diff <= 3.
ZBW_PARAM-ZKEY1 = 'INV_SHORT_REQ'.
ZBW_PARAM-ZKEY2 = SOUR_TAR.
ZBW_PARAM-ZDATA = IT_REQ_CUBE_WA-RNR.
MODIFY ZBW_PARAM.
ENDIF.
endloop.

Once after reqnumb is found out, you can pass
cubename, reqnumb as inputs to FM : RSSM_DELETE_REQUEST and get the job done.