cancel
Showing results for 
Search instead for 
Did you mean: 

Short dump: GETWA_NOT_ASSIGNED

04-29-2015 4:00 PM
16065 views 13 comments Go to solution
0 Likes
Subscribe

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.

0 Likes

Accepted Solutions (1)

Accepted Solutions (1)

former_member183290
Participant
0 Likes

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.

former_member183290
Participant
0 Likes

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.

Answers (2)

Answers (2)

Former Member
0 Likes

Hi

I think the issue is with the fieldsymbol.

Is there any code.

If yes  pls paste it.

former_member183290
Participant
0 Likes

Hi Ravi, I have attached the Dump in the first message. Can you please check it and suggest? Thanks, Vikranth.

Former Member
0 Likes

Hi Madhav,

That dump mean the field-symbol is not assigned to anything.

As you are assigning with string, so... there are chance that you have a typo and the assignment failed.

Anyway, try to debug on your assign statement see if you have any new finding.

Regards

Bill

former_member183290
Participant
0 Likes

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.

Former Member
0 Likes

Hi Viranth,

I think that your error is at this level:

                                                  |                                                                                      |

|>>>>>|    INSERT ls_error_log INTO TABLE <lt_error_log>  .                                        |

<lt_error_log> is not a table, but a field symbol.


Amine



former_member183290
Participant
0 Likes

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.

Former Member
0 Likes

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

Former Member
0 Likes

Hi madhav,

Can you pls paste the data.

Looks like data quality issue..

KodandaPani_KV
Active Contributor
0 Likes

Hi,

can you activate the data source through program

3.x - RS_TRANSTRU_ACTIVATE_ALL

7.x- RSDS_DATASOURCE_ACTIVATE_ALL

after run the info pacagke.

if have so many request in the PSA delete all then try it.

do testing in dev system not in the PRD system.

Thanks,

Phani.

former_member183290
Participant
0 Likes

Hi Phani,

Data is loading fine till PSA. Only at the DTP level we are having this issue.

Also, we are loading the data as part of unit testing. So, there aren ot too many requests too.

former_member183290
Participant
0 Likes

Hi Ravi,

Please find the screenshot. We have got this error in DTP. We tried to edit the PSA by nullifying the value and save the PSA record.

But, it says REQU_* does not found. Though we are taking the request and edit it.