Chinaunix首页 | 论坛 | 博客
  • 博客访问: 97128
  • 博文数量: 55
  • 博客积分: 530
  • 博客等级: 中士
  • 技术积分: 460
  • 用 户 组: 普通用户
  • 注册时间: 2010-11-02 11:21
个人简介

大龄ABAP自由顾问

文章分类

全部博文(55)

文章存档

2016年(1)

2015年(4)

2014年(14)

2013年(2)

2012年(3)

2011年(31)

我的朋友

分类: 项目管理

2011-08-12 15:39:05

One of the first questions we ask when we are going to implement a new logic in an SAP user exit is: what kind of data is available as input and what can I modify as output? Though limited, most of the time the parameters of user exit functions let us do what we want. But sometimes we get stuck because some field is not provided. The field can be either some global field of the calling program or a global field in a function group that is used by calling program. (You should remember that in latter case, the data is still sitting in the memory until we exit the main program or transaction, and can be used by any subsequent calls).
 
There is a simple trick that allows you read and modify the global data of any module loaded by a running program. It is using the ABAP’s dynamic assignment feature of field-symbols. The best way is to show it with an example.
 
The user exit ZXCO1U06 is running when we save a production order in the transaction CO02. In this user exit you can do some additional checks, modify data, probably issue some messages and so on. Unfortunately, only header data of the order is provided as its parameter. Reading the database is not an option because any updated data (new operations, new status flags) is not yet written to the database. If you want to read, say, order operations or their status, you either call the same functions that are called by CO02 (as the same global data is used), or access the data directly. If we want to check the status of the order and ist operations, we could read the global data (internal tables) of the function group BSVA, that is used to manage the status in CO02. The table that contains the status flags is called JEST_BUF and we can get the table content in out user exit in the following way:
 * See declarations in LBSVATOP
* This type should match the one used in SAP program!
types: begin of t_jest.
            include structure jest_upd.
types:
            mod,
            inact_old like jest-inact,
          end of t_jest.

data:
  lf_text(40)   type c,
  lt_jest       type standard table of t_jest.

field-symbols:
        type any table.

lf_text = '(SAPLBSVA)JEST_BUF[]'.
assign (lf_text) to .
check sy-subrc = 0.
lt_jest[] = .  "now everything is in lt_jest !
If we want to do some changes of the global data, we could do a “reversed” assignment to the field-symbol:
  = lt_jest[].
Finding the needed program and variable names is not a straightforward task, but can be done with debugger. The best motivation is that there is rarely some alternative solution (that is less ugly than using dynamic ABAP assignments).
 
Important note: Using user exits is a kind of advanced task because you can easily screw up the SAP program’s internal data. But this trick gives you even more chances of doing that, so everything should be done with a special care.

阅读(444) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

langziqian2011-08-12 15:43:04

I already used these tricks to get the required data from the “old” transactions.

I am now however stuck in transaction ME22N, It uses classes (objects) and I am still trying to find a way to access an existing object in memory without knowing its address.
All I know is that if I look in the debugger the variable my_model contains that following value {O:687*\CLASS=CL_PO_HEADER_HANDLE_MM}.

With the cl_po_header_handle_mm I should be able to retrieve the ob