Hello all, We have already checked various posts regarding the same issue. As per the existing forums, some are experiencing the error at cube level, BeX analyzer level. We are facing the below Dump, when we are loading the data from PSA to First level ODS. Dump: The internal session was terminated with the runtime error GETWA_NOT_ASSIGNED (see ST22). Attached the dump as well. Also, we are coming through this short dump only for those flows where we have enhanced the function modules & enhanced the existing flows. (Not sure if it is just a coincidence or is there any issue with the enhancement we have done). Wherever we have developed the new flows, we aren't facing any loading issues. Loading is going fine for the newly staged ODSs. 1) So, is there anything that went wrong with enhancing the FMs? 2) Do we need to check the mappings as we have Key figures & related units? Because, I checked the dump & noticed that there is wrong with the unit part. I could not understand the exact issue on what is the root cause. We also read the forums where we need to correct the routines, however there are no routines that were used in between the PSA & ODS at which the loading is happening. We are only using the fields from ODS to the next level lookup which is not related to the below DTP loads. Can anyone provide me some inputs as we are at crucial state of loading. Thanks, Vikranth.
Request clarification before answering.
Hello all,
Also, to brief you on more details; we enhanced the existing data source FM with the PLPO-VGW02, VGE02, VGW03, VGE03 fields for getting the Equipment & Labor quantities and their respective unit of measures.
We mapped these in BW transformations. And when we are triggering the DTP, we are getting the issue. We checked in st22 (ABAP editor) & found the below conversion error.
D00069005 is the unit IO that we created in BW for mapping the VGE02 unit. Is there anything that we missed while using these units?
Thanks,
Vikranth.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello all,
Issue is resolved.
As said above, D00069005 is the BW info object that we have created for VGE02 unit.
We are facing the short dump, while the unit conversion is happening.
We noticed that, there are few entries in PSA table for VGE02 (Standard value of Unit) which is not maintained in T006 table.
Usually, in T006 table - for every UOM, we will have an entry maintained.
In Development system, one of the value 'TST' is not maintained. Hence we faced the short dump as the value could not be converted due to no table entry.
We either need to maintain the entry if in PROD or can edit the PSA / filter out the entries if it is not in production.
Thank you all for taking your time & looking into this.
Regards,
Vikranth.
Hi
I think the issue is with the fieldsymbol.
Is there any code.
If yes pls paste it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Extremely sorry on how the message is getting displayed. I tried to format it multiple times to keep it in points but, it is coming as a single message. Please try to check the issue and provide any suggestions. Thanks, Vikranth.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Amine, Can you elaborate a little on the line that you mentioned? Also one more point, I checked the DTP error & I found that there is any entry which is erroneous. But, when I tried to remove that entry by editing the PSA table & save the request; It says REQ_* not found. Do you have any clue on this? Thanks, Vikranth.
Madhav,
it's an extract from your code:
|Line |SourceCde |
----------------------------------------------------------------------------------------------------
| 1851| USING |
| 1852| record_no TYPE sy-tabix |
| 1853| source_system TYPE rsa_logsys |
| 1854| iobj_name TYPE rsiobjnm |
| 1855| r_request TYPE REF TO if_rsbk_request_admintab_view |
| 1856| CHANGING |
| 1857| result TYPE lcl_transform=>_ty_s_TG_1-UNIT |
| 1858| returncode TYPE sy-subrc. |
| 1859| |
| 1860| DATA: ls_error_log TYPE rssm_s_errorlog_int. |
| 1861| FIELD-SYMBOLS: <lt_error_log> TYPE rssm_t_errorlog_int. |
| 1862| |
| 1863| ASSIGN ('G_T_ERRORLOG') TO <lt_error_log>. |
| 1864| |
| 1865| CALL METHOD zcl_g_routines=>check_uom |
| 1866| EXPORTING |
| 1867| iv_logsys = SOURCE_SYSTEM |
| 1868| IMPORTING |
| 1869| ev_returncode = RETURNCODE |
| 1870| CHANGING |
| 1871| cv_uom = RESULT. |
| 1872| |
| 1873| IF RETURNCODE NE 0. |
| 1874| |
| 1875| ls_error_log-record = RECORD_NO. |
| 1876| ls_error_log-msgty = 'E'. |
| 1877| ls_error_log-msgid = 'ZG_EDWH'. |
| 1878| ls_error_log-msgno = '003'. |
| 1879| ls_error_log-msgv1 = RESULT. |
| 1880| |
|>>>>>| INSERT ls_error_log INTO TABLE <lt_error_log> . |
| 1882| |
| 1883| ENDIF. |
| 1884| |
| 1885|* RESULT = . |
| 1886|* RETURNCODE = 0. |
| 1887|ENDFORM.
Is this code a standard or specific one?
Amine
| User | Count |
|---|---|
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.