转 : authority object,luw,data cluster,bapi等

最新推荐文章于 2024-02-07 22:09:49 发布

DJ2008

最新推荐文章于 2024-02-07 22:09:49 发布

阅读量634

点赞数

分类专栏： SAP 文章标签： object authorization database application table buffer

SAP 专栏收录该内容

79 篇文章 3 订阅

订阅专栏

转自：scnblogs.techweb.com.cn/abaplv/archives/212.html

authority object,luw,data cluster,bapi等

sub5 为了使具有相应权限的人能够访问相应的数据，开发人员必须在SAP系统中实施authorization object。为了达到这个目的，你需要首先开发一个与应用逻辑相关的权限模型，在ABAP WORKBENCH中你需要创建authorization object并在其基础上创建authorization。权限是通过authorization profile分配给用户的。在程序中检查用户是否具有执行相应动作的权限。应用开发人员必须在执行相应的action之前检查相应的权限。Sap在自己的software中了应用了相应权限的概念，作为客户也应当应用相同的权限的概念在对sap的增强或开发的独立应用中。SAP有相应的管理权限和分配权限的工具。

一个authorization object最多可以有十个字段，不过这些字段并没有值。而authorization就是对authorization object赋值的结果。一个authorization object可以产生多个authorization。一系列authorizations可以组合到authorization profile中。一个authorization profile应当包含执行某个特定任务所需的所有权限。Authorization profiles可以分配给用户。Authorization object维护的事务为Tools->ABAP Workbench->Development->other tools->Authorization object。可以通过AHTUORITY-CHECK语句实现权限的检查，一个语句用于检查authorization object和其field value。如果某个特殊的权限对某些field的内容并不关心，那么可以使用dummy代替field <value>。这可以实现更加灵活的权限检查。当具备相应的权限时AUTHORITY-CHECK就会给sy-subrc赋值0否则的话就会赋值4。

事务启用时的权限检查过程：

l 事务代码在表TSTC中是否存在

l 该事务代码在表TSTC中是否被锁住

l 用户是否具有s_tcode对应的该事务代码的authorization

l 然后检查分配给这个事务代码的缺省的权限对象。

只有这个四个步骤都通过时，才会启动事务。而AUTHORITY-CHECK语句只有事务启动以后才会检查。

SAP的DATABASE TABLE可以被buffer到application server上，这么做的主要目的有：

l 减少对数据库的直接访问，提高访问速度

l 减少对数据库的负载

Buffered table只能被database interface访问。

如果执行Native SQL就会绕过database interface，当然也就不能够使用SAP R/3的database buffer了，因此应当避免使用Native SQL修改buffered table的数据，以免造成数据的不一致。并不是所有的OPEN SQL都会去读table buffer。

Open sql修改数据的结果时数据库中的数据以及运行这个sql的application server的table buffer中的数据都会被改变。如果table被buffer在不同的application server上，这些application server的buffer会延迟同步，过程如下：如果数据库中的数据被一个application server更改，修改得数据被注册在数据库表DDLOG中。Application server会每个周期读一下这个表，如果发现相应的记录，buffer中的该条记录就会被标识为no longer up-to-date。下次读取buffered table的数据时database interface就会从数据库中读取数据并更新buffer content。Interval的大小是有profile parameter：/rdisp/buffertime定义的。有三种buffer的类型：

l Resident buffer(100%)第一次访问表时，表中的所有内容都被buffer

l Generic buffer：一个generic key(前n个key)在ABAP Dictionary中必须被定义。这个key用来把table content划分成generic areas。如果generic area的一条数据被访问，整个generic area都会被放到table buffer中。集团相关的表基本上是按照集团buffer的

l Single-record buffer.只有被访问的记录才会放到table buffer中

Native SQL可以做的操作远远超出标准OPEN SQL的范围。其不仅可以操作本地数据库还可以操作分散数据库。Native SQL既可以做DDL也可以做DML。不过对于error handle和声明host variables并不支持。EXEC SQL…END EXEC必须封装一个NATIVE SQL语句，NATIVE SQL操作的表不需要再ABAP DICTIONARY中声明。NATIVE SQL的语法与数据库是相关的。Native SQL可以执行的DDL：CREATE (TABLE,VIEW,INDEX)，

DROP (TABLE,VIEW,INDEX)，ALTER （TABLE VIEW INDEX），GRANT，REVOKE。可以执行的DML：SELECT INSERT UPDATE DELETE DECLARE CURSOR FETCH CURSOR OPEN CURSOR CLOSE CURSOR

Data cluster是data objects的组合。Data object可以是fields, structured fields, internal tables以及complex data objects。可以通过ABAP语句EXPORT，IMPORT和DELETE来操作data cluster。Data cluster可以存储在cluster database中。可以通过application area来划分cluster database的区域。Application area的name是由两个字符组成的。同一个application area的cluster是通过cluster id来区分的。

对于export需要一个cluster database，table INDX是一个cluster database。Cluster database在ABAP dictionary中是transparent table并有standardized structure。执行EXPORT需要指定cluster database及其application area。通过cluster ID来区分cluster本身。如果cluster中的field name与program中的不同可以通过addition from来实现。对于export没有任何write protection。数据在cluster database中是以压缩的形式存储的。程序启动时，可以通过TABLES语句来声明cluster database的application area。Internal table的headline不能被export。

EXPORT <NAME> FROM <obj>

[obj]

TO DATABASE <dbtab>(<ar>) ID <id>

例：REPORT XXX.

TABLES indx.

EXPORT

….

…

TO DATABASE indx(<ar>)

ID <id>

对于IMPORT你只需要列出cluster data objects的子集，如program中的变量的名称与cluster中data object的名称不同可以通过addition TO来实现。通过sy-subrc来返回IMPORT执行的结果，如果不成功sy-subrc <> 0。Field，structure和internal table的结构与cluster中相应object的必须相同，否则就会产生runtime error。IMPORT时所使用的field name与EXPORT时所使用的field name必须相同。如果cluster存在sy-subrc = 0，而不管data field是否被imported。DELETE用来删除整个cluster。DELETE也通过return code返回结果。

IMPORT <name> TO <obj>

[obj]

FROM DATABASE <dbtab>(<ar>) ID <id>

例：REPORT XXX.

TABLES indx.

IMPORT

…

…

TO DATABASE indx(<ar>)

ID <id>.

可以通过下面的步骤自己创建abap cluster database;

l 在abap dictionary中建立一个transparent table，用来存储cluster database

l 建立table structure

l MANDT FIELD可以被ommit

l 字段RELID,SRTF2,CLUSTER,CLUSTID和cluster id在EXPORT的时候会被自动填充。

l 自定义的字段要在export之前填充，这些字段的值可以被IMPORT获取

l 选择cluste ID的field name和你自己的fields，剩余的field是由系统确定的。

l 通过structure的总体长度减去前六个字段的长度可以得到数据所占的长度。

INDX是可以存储cluster的一个例子，其在系统中是缺省安装的，它的key field的长度为31byte，除了key field和data cluster还有一些字段用来存储管理系信息。不如change, validate date, create by等。可以在EXPORT之前来填充这些信息。比如：MOVE SY-DATUM TO INDX-AEDAT。Cluster table和transparent table的区别：cluster table用来存储cluster，很少访问大量数据，存储的是异构数据，灵活的技术，不能用于link access，需要cluster ID和application area才能访问，其返回结果只能是是一个cluster。而对于transparent table可以多次访问，支持link access可以通过logical condition限制访问的数据。

对于scope = 1的lock，dialog program拥有其产生的lock，lock在其被释放之前依然存在，可以通过DEQUEUE_<OBJECT>释放lock，也可以在程序结束时implicitly release。这包括语句：LEAVE PROGRAM，LEAVET TO TRANSACTION <TA>和SUBMIT <program>以及termination messages。如果事务使用用异步更新，就无法保证出现要修改的数据被其他用户lock住。所以对于异步更新不应当使用_scope1 = 1的lock。

对于异步更新，应当保证dialog program产生的Lock比V1 update program active的时间要长，可以通过_scope = 3来做到这点。通过_scoped = 3产生的lock既要被dialog program释放又要被update module释放。

BAPI可以看作为SAP ERP的gateway，它是business object的method，可以实现：创建object，查询object的某些属性和修改object的某些属性。BAPI是外部系统访问SAP ERP

的interface。BAPI是object-oriented的，其是business object的method。BAPI的INTERFACE是稳定的，对客户是开放的，interface parameter是通过data element来定义的。既可以外部调用也可以内部调用。BAPI没有presentation layer。BAPI一般是同步调用，IDOC中的ALE例外，其在目标系统中依然是同步调用。可以通过update task实现数据更新。BAPI中不能使用COMMIT WORK。而要使用service object的method：BAPI_TRANSACTION_COMMIT和BAPI_TRANSACTION_ROLLBACK。BAPI使用了TRANSACTION MODEL，一个transaction代表了一个process unit或LUW。修改数据库的动作必须通过update task实现。这样可以实现将多个BAPI放到一个LUW中。可以通过FM：BAPI_TRANSACTION_COMMIT来关闭LUW。