BAPI_COMPANYCODE_GETDETAIL是一个适合演示的函数，没有import paramter参数，调用后COMPANYCODE_GETDETAIL 表参数返回SAP系统中所有公司代码的清单。只包括公司代码ID和公司代码名称两个字段。
以前做enhancement的时候用过parameter id 和 memory id, 但很多其他语法用法我是没接触过的, 今天看了Palm同鞋做的文档SAP Memory & ABAP Memory, 做了一些测试, 本文几乎所有内容来自Palm同鞋的文档.
该文主要是深入探讨在ABAP开发中如何使用SAP提供的应用层的锁机制来保证数据库表中的数据一致性。
一，过程 1，DIALOG程序获得用户要更新的数据，并把它写到一个特殊的LOG TABLE，表内的条目属于同一个请求类型，包含了稍后将要写到数据库的数据。一个DIALOG程序可以写多条数据到LOG TABLE。写进LOG TABLE里的条目属于同一个LUW，意思就是它们要么都被执行，要么都不被执行。 2，DIALOG程序关闭LUW（将LOG TABLE的条目打包），并通知系统基本程序有一个包的数据需要更新。 3，系统基本程序从LOG TABLE读取这个LUW的需要更新的数据，并把这些数据提供给系统更新程序。 4，系统更新程序接受传输给它的数据，并更新数据库。 5，如果更新程序运行成功，系统基本程序删除这个LUW在LOG TABLE的所有数据；如果失败，保持LOG TABLE的这些数据，并标记不成功。触发更新程序的用户会收到系统发的关于这个错误的E-MAIL。可以用参数rdisp/vbmail（1发，0不发）来控制错误时是否发E-MAIL和rdisp/vb_mail_user_list（$ACTUSER代表创建更新数据的用户）来控制错误时发E-MAIL给谁。可以用事务SM13来监控更新请求。 二，技术实现 更新程序必须用一个特殊的FM（update module）来实现。UPDATE MODULE和其他的FM一样，有传输参数的接口，但是只能有IMPORTING和TABLES，并且类型只能用参考或者结构。EXPORTING和EXCEPTION参数在UPDATE MODULE里是被忽略的。UPDATE MODULE里包含实际的数据库更新语句。 在DIALOG程序中，通过一个特别的FM，使用IN UPDATE TASK。如： CALL FUNCTON 'F1' IN UPDATE TASK EXPORTING P1 = A P2 = B. 使用这样写法的FM不会立即执行，而是写进LOG TABLE，作为一个执行请求，一个SAP LUW下的更新请求存储在同一个UPDATE KEY下。对一个SAP LUW来说UPDATE KEY是一个唯一的世界范围的识别码，意思就是一个SAP LUW的UPDATE KEY是唯一的，不会和另外的SAP LUW的UPDATE KEY重复。 只有当程序执行到COMMIT WORK的时候，才会为这些请求创建一个抬头条目LOG HEADER，表示以上这些同样UPDATE KEY的属于同一个包，然后系统关闭这个LUW。当LOG HEADER创建以后，系统通知DISPATCHER有一个更新包已经准备好可以处理了。 有些时候，你可能需要丢弃当前SAP LUW的所有changes（比如结束TCODE），可以使用ROLLBACK WORK或者弹出一个A类型的MESSAGE，这两个语句都可以有以下的效果： -删除写到该点之前的所有的change requests -删除写到该点之前所有的锁 -丢弃当前DB LUW执行的changes -丢弃所有使用POC形式登记的subroutines ROLLBACK WORK语句不会影响程序上下文，意思就是，所有的数据对象保持不变。UPDATE MODULE里面不允许有显示的ROLLBACK WORK或者COMMIT WORK语句。 如果更新失败，属于这个SAP LUW的LOG条目会标记成不正确，同时错误消息也会保存到日志。可以用SM13来检查LOG条目。 如果在DIALOG程序里为更新技术设置了锁，并且锁的参数_scope = 2，那么使用COMMIT WORK之后锁会被传递到UPDATE TASK，这个时候在DIALOG程序中，锁不能被访问。 在UPDATE MODULE里不必显示的去释放锁，因为更新处理的最后阶段，系统会自动释放这些锁。当UPDATE TASK有错误发生的时候，也会自动释放锁。 如果UPDATE MODULE允许更新请求再次被处理，在处理的时候数据库中的数据表跟失败的时候可能不一样，而且也没有锁保护了，因为错误产生的时候，锁自动被释放了。 举个例子，如果一个凭证没有成功更新到数据库是因为数据库的表空间溢出，这个时候比较适合再次处理。 三，更新的模式 1，异步模式 在这个模式下，DIALOG程序和UPDATE程序各自运行。DIALOG程序写请求到LOG TABLE，用一个COMMIT WORK来关闭LUW。UPDATE程序被COMMIT触发并开始运行来处理这些请求，DIALOG程序继续运行，不会等待UPDATE程序结束。UPDATE程序在特殊的UPDATE WORK PROCESS中运行。 当数据库更新花费比较长的时间，用户DIALOG需要较少的响应时间，异步更新显得比较重要。在DIALOG处理中，异步更新是标准的技术
一，过程 1，DIALOG程序获得用户要更新的数据，并把它写到一个特殊的LOG TABLE，表内的条目属于同一个请求类型，包含了稍后将要写到数据库的数据。一个DIALOG程序可以写多条数据到LOG TABLE。写进LOG TABLE里的条目属于同一个LUW，意思就是它们要么都被执行，要么都不被执行。 2，DIALOG程序关闭LUW（将LOG TABLE的条目打包），并通知系统基本程序有一个包的数据需要更新。 3，系统基本程序从LOG TABLE读取这个LUW的需要更新的数据，并把这些数据提供给系统更新程序。 4，系统更新程序接受传输给它的数据，并更新数据库。 5，如果更新程序运行成功，系统基本程序删除这个LUW在LOG TABLE的所有数据；如果失败，保持LOG TABLE的这些数据，并标记不成功。触发更新程序的用户会收到系统发的关于这个错误的E-MAIL。可以用参数rdisp/vbmail（1发，0不发）来控制错误时是否发E-MAIL和rdisp/vb_mail_user_list（$ACTUSER代表创建更新数据的用户）来控制错误时发E-MAIL给谁。可以用事务SM13来监控更新请求。 二，技术实现 更新程序必须用一个特殊的FM（update module）来实现。UPDATE MODULE和其他的FM一样，有传输参数的接口，但是只能有IMPORTING和TABLES，并且类型只能用参考或者结构。EXPORTING和EXCEPTION参数在UPDATE MODULE里是被忽略的。UPDATE MODULE里包含实际的数据库更新语句。 在DIALOG程序中，通过一个特别的FM，使用IN UPDATE TASK。如： CALL FUNCTON 'F1' IN UPDATE TASK EXPORTING P1 = A P2 = B. 使用这样写法的FM不会立即执行，而是写进LOG TABLE，作为一个执行请求，一个SAP LUW下的更新请求存储在同一个UPDATE KEY下。对一个SAP LUW来说UPDATE KEY是一个唯一的世界范围的识别码，意思就是一个SAP LUW的UPDATE KEY是唯一的，不会和另外的SAP LUW的UPDATE KEY重复。 只有当程序执行到COMMIT WORK的时候，才会为这些请求创建一个抬头条目LOG HEADER，表示以上这些同样UPDATE KEY的属于同一个包，然后系统关闭这个LUW。当LOG HEADER创建以后，系统通知DISPATCHER有一个更新包已经准备好可以处理了。 有些时候，你可能需要丢弃当前SAP LUW的所有changes（比如结束TCODE），可以使用ROLLBACK WORK或者弹出一个A类型的MESSAGE，这两个语句都可以有以下的效果： -删除写到该点之前的所有的change requests -删除写到该点之前所有的锁 -丢弃当前DB LUW执行的changes -丢弃所有使用POC形式登记的subroutines ROLLBACK WORK语句不会影响程序上下文，意思就是，所有的数据对象保持不变。UPDATE MODULE里面不允许有显示的ROLLBACK WORK或者COMMIT WORK语句。 如果更新失败，属于这个SAP LUW的LOG条目会标记成不正确，同时错误消息也会保存到日志。可以用SM13来检查LOG条目。 如果在DIALOG程序里为更新技术设置了锁，并且锁的参数_scope = 2，那么使用COMMIT WORK之后锁会被传递到UPDATE TASK，这个时候在DIALOG程序中，锁不能被访问。 在UPDATE MODULE里不必显示的去释放锁，因为更新处理的最后阶段，系统会自动释放这些锁。当UPDATE TASK有错误发生的时候，也会自动释放锁。 如果UPDATE MODULE允许更新请求再次被处理，在处理的时候数据库中的数据表跟失败的时候可能不一样，而且也没有锁保护了，因为错误产生的时候，锁自动被释放了。 举个例子，如果一个凭证没有成功更新到数据库是因为数据库的表空间溢出，这个时候比较适合再次处理。 三，更新的模式 1，异步模式 在这个模式下，DIALOG程序和UPDATE程序各自运行。DIALOG程序写请求到LOG TABLE，用一个COMMIT WORK来关闭LUW。UPDATE程序被COMMIT触发并开始运行来处理这些请求，DIALOG程序继续运行，不会等待UPDATE程序结束。UPDATE程序在特殊的UPDATE WORK PROCESS中运行。 当数据库更新花费比较长的时间，用户DIALOG需要较少的响应时间，异步更新显得比较重要。在DIALOG处理中，异步更新是标准的技术，意思就是DIALOG程序一般会采取异步更新方式。 可
1, 使用function module SUSR_USER_PARAMETERS_GET
1、FM的功能定位 1.1 、FM模块的主要功能定位 话说当前各个实体企业都在提出精细化管理，因此有一天相关人员组织了一场讨论大会，参加人员有外企、国企、民企、还有个体户，X-SAP也混在其中，想趁机推广一下SAP。 外企：我们制定了合理的预算，并严格遵守和执行，一年下来，我的费用得到有效控制，并减少了费用成本的开支，提高了企业的竞争能力…… 国企：我们制定了各种各样高大上的预算，使用相当漂亮的报表，并提供领导决策，领导对我们编制的预算非常满意，我们的预算取得了成功，并成功的进行了预算。 外企：你们按需求
相关物料基本计量单位是PC, 而面积信息的维护方式，根据物料的不同而不同。一般物料是维护在物料主数据里（MARM表），但是客户有许多业务是关于可配置物料的按单生产与销售的。对于这部分可配置物料的面积，是维护在销售订单里。客户需要按其客户要求的尺寸比如长宽等信息，维护在具体的销售订单里。
3.1.5 主数据的细分 FM模块还提供了对账户分配要素主数据的细分支持，将账户分配要素的主数据，按照企业需要的规则来细分段，每一段的单独编码都有着相应的含意，主要起充分挖掘和规范主数据的使用，并方便后期报表中按照账户分配要素单独的分细段进行报表分析（例如在报表库4FM中将细分数据特性放出来，即可支持单独细分段的报表查看）。 前面讲的承诺项目的掩码规则跟这个主数据的细分本身作用有区别，同时体现在系统也是有区别的，掩码规则只是格式化显示，在数据库表中数据不包含掩码符（类同WBS的掩码规则），主数据的细分，在数
声明：本文仅代表原作者观点，仅用于SAP软件的应用与学习，不代表SAP公司。注：文中所示截图来源SAP软件，相应著作权归SAP所有。
3.1.1.2 承诺项目主数据维护 1）FMCIA - 单个处理 维护单个的承诺项目。 ① image.png ② 直接可记账的：该承诺项目可以在预算生成和预算耗用中直接记账使用。 ③ 不能直接可记
JCo3.0调用SAP函数的过程 大致可以总结为以下步骤： 连接至SAP系统 创建JcoFunction接口的实例（这个实例代表SAP系统中相关函数） 设置importing参数 调用函数 从exporting参数或者table参数获取数据 代码： package jco3.demo4; import org.junit.Test; import com.sap.conn.jco.JCoDestination; import com.sap.conn.jco.JCoDestinationManager
3.1.6 账户分配要素主数据权限检查 在FM模块当中部份主数据的权限检查，SAP支持不是很好，比如对基金计划程序的权限支持不是很好。针对集团式管控的企业，对FM主数据有着细分权限管理需求，除了使用权限组外，可以增强对账户分配要素主数据的权限检查，例如，自建一个基金计划程序的权限对象，然后用于基金计划程序的权限检查。 因此可以激活BADI：FM_AUTHORITY_CHECK 来增强用户自定义的权限检查。 该BADI提供了以下几种方法，来扩展增强权限检查： FM_AUTHORITY_CHECK~COMMIT
假设MAIN PROGRAM（调用程序）为MAIN，其所在的为SAP LUW 1。
一，同步调用从一个程序同步调用其他的ABAP程序，有2种方式： 1，调用程序被打断，当被调用程序执行完毕之后，调用程序继续执行。如：CALL FUNCTION <function>SUBMIT <program> AND RETURNCALL TRANSACTION <tcode> 使用CALL FUNCTION 'AAA'调用FM的时候，相应的FUNCTION GROUP被加载到调用程序所在的internal session。当FM执行完毕，接着执行调用程序。FUNCTION GROUP和其GLOBAL DATA会一直保存在这个internal session直到调用程序结束。当调用程序再次调用这个FM的时候，不会再次加载相应的FUNCTION GROUP。这个FUNCTON GROUP的GLOBAL DATA和第一次调用它时的内容是一样的。 使用SUBMIT <program> AND RETURN或者CALL TRANSACTION <tcode>的时候，实际是插入了一个新的internal session，当被调用的程序执行完毕之后，新插入的internal session会被删除，继续执行调用程序。可以使用leave program语句来结束程序。
20201228学习《ABAP_ALV_知识整理》，以下为读书笔记和我的ALV开发实例。
其本义是：异步通信时，通信双方时钟允许存在一定误差；同步通信时，双方时钟的允许误差较小。在SAP的系统间的通信过程中，也借用术语同步通信和异步通信，但其主要差异在于调用系统是否需要立即接受返回结果。这两种通信模式各有局限性，不同的应用适用于不同的通信模式。
SQL 监控：事务 SQLM 将管理任务作为目标/事务 SQLMD 用于数据记录分析
如果SAP中多个函数需要在一个session中运行，需要JCoContext来提供保证。如果在同一个线程中，大体模式这样：
3.1.4 基金计划程序 基金计划程序是可选账户分配要素，可以用它来进行跨公司、跨年度的框架内预算控制，比如一个大型项目。它同其他账户分配要素不同，它可以直接进行预算，但不能在预算消耗中的账户分要配界
ABAP 的 CALL FUNCTION 类似于 Java/.NET 中的本地或远程方法调用。 CALL FUNCTION 可以分为四种： 1. Synchronous RFC (sRFC) - 同步调用 2. Asynchronous RFC (aRFC) - 异步调用 3. Transactional RFC (tRFC) - 保证 Transaction 数据一致性的调用 4. Queued RFC (qRFC) - 用一个对列序列化的 tRFC 本文很好地介绍了前面两种，也是最常用的两种。 SAP Help 的相关文档是： http://help.sap.com/SAPhelp_nw04/helpdata/en/9f/db98ef35c111d1829f0000e829fbfe/frameset.htm Calling Function Modules http://help.sap.com/saphelp_nwpi71/helpdata/en/8f/53b67ad30be445b0ccc968d69bc6ff/frameset.htm CALL FUNCTION
在制药行业里经常有这样的场景或者需求：成品工单是一个包装工单，将生产好的半成品加上内外包材，经过包装后做成可以交付给客户的成品，成品的批次的属性本质上跟被包装的半成品的批次一致，批次号保持一致。
4 派生规则推导策略 派生规则推导，是SAP提供由数据源推导到目标数据的一种工具，它提供了一系列面向用户开放使用的方法来使数据源经过逻辑推理后生成了有效目标数据。比如已知业务发生形成的源数据A，经过了一个复杂的逻辑推导，得到B，然后把B作为结果来使用。 我们可以开放的理解一下，在由源数据推导到目标数据的过程中，由于SAP系统无法列举可能的业务模式或者业务逻辑来供用户配置，于是就提供了一个开放的由用户自己定义一段程序来达到这个目的，你没有看错就是一段程序,而实现这段被SAP规范的程序的工具就是派生规则推导工具
一、认识BTE BTE（Business Transaction Event）也称之为“业务交易事件”,一般的增强(Tcode:SMOD|CMOD)依旧使用ABAP进行二次开发,然而BTE则提供了RFC调用其它产品的可能(Tcode:FIBF)。BTE的设计思路更加简单，和BADI有点类似。在标准程序中留有OPEN_FI的出口(以函数OPEN_FI_PERFORM_eventid_type的形式存在)，提供一个可配置的TABLE，可以在里面针对某个特定的Event维护自己定义的出口函数，标准程序走到这里，如果查出用户定义了出口函数，则会调用，达到增强的目的。 BTE增强有2种类型，类似于会计凭证的验证和替代。 P/S函数模块（Publish and Subscribe Interface）:只提供SAP数据源，可以供外部程序使用或者达到数据检查的目的。 处理函数模块（Process Interface）:可以达到数据修改的目的，用来增强标准的业务流程。
应用层运行着DIALOG进程,每个DIALOG进程绑定一个数据库进程,DIALOG进程与GUI进行通信,每次GUI向应用服务器发送请求时都会通过dispatcher服务为每个GUI的请求分配一个Dialog进程.一个程序运行时,GUI与Dialog进行需要多次通信,每次通信使用的Dialog进程不一定相同,在Dialog进程将控制权转给前台的GUI时,由于Dialog进程同数据库进程绑定,会触发一个隐式数据库提交(COMMIT WORK),如果在Dialog进程发生A类型错误,则触发隐式的数据库回滚(Rollback) SAP LUW SAP LUW是DB LUW的一个增强,受体系结构限制,SAP程序每次屏幕切换时(控制权从后台DIALOG进程转移到前台GUI的Session),都会触发一个隐式的数据库提交,一个程序在运行是会产生多个DB 的LUW,这样无法做到全部提交或全部回滚,在某些业务场景下,这种事务的提交机制不足以保证数据的一致性,为此有有了SAP LUW机制.SAP LUW是一种延迟执行的技术,它将本来需要执行的程序块,记录下来.记录的位置在内存或DB Table中,如perform on commit 会记录到内存中,update Funciton module即可以记录到内存也可以记录到VBMOD 和VBMOD表中.系统在执行COMMIT WORK的时候会查询记录,真正执行需要运行的代码,COMMIT WORK一般在最后一个屏幕执行,这样就实现了将跨屏幕的数据更新逻辑绑定到一个DB LUW中,实现复杂情况数据更新的一致性 SAP LUW的绑定方式 CALL FUNCTION...IN UPDATE TASK, 该种方式需要Funciton类型为Update Module类型,同时在调用时使用IN UPDATE TASK参数. 在程序调用 Update Module进行更新时分为本地和非本地 非本地方式: 注册的更新函数记录在VBMOD 和VBMOD表中,COMMIT WORK 时更新操作在UPDATE进程中执行,此时调用程序不等待被调用函数的返回,使用的为异步方式.如果使用COMMIT WORK AND WAIT,此时调用程序等待被调用函数的返回,使用的为同步方式. 本地方式 在调用函数前需要执行 SET UPDATE TASK LOCAL. 这样所有在该语句后使用CALL FUNCTION...IN UPDATE TASK注册的更新函数不会记录到数据库中,而是记录在内存中,在Commit work之后,会从内存取得待执行的函数,在同一个Dialog进程中执行数据的更新,本地方式更新采用的是同步方式,即使在Commit work后指定了and wait参数,仍然是同步执行. 在使用COMMIT WORK之后 SET UPDATE TASK LOCAL的效果会被清除掉,如果COMMIT WORK后注册的更新函数仍然需要采用本地方式,需要再执行一次 SET UPDATE TASK LOCAL语句. 优缺点对比 本地方式不将待执行的更新函数写到数据表中,减少了I/O操作,效率上较高,但由于采用的是同步方式,程序需等待更新结果,用户交互时的会感觉程序运行较慢 非本地方式会将更新结果记录到数据表中,可以通过SM13查看更新情况,同时由于可以进行异步更新,用户交互时感觉会比较快 CALL FUNCTION... IN BACKGROUND TASK DESTINATION, 是一种对RFC函数进行事务绑定的方式
In SAP Transportation Management, we get many scenarios to trigger a PPF (Post Processing Framework) Action by stand alone code. Examples being; Trigger a PPF Action from a POWL (Personal Object Work list) or trigger a PPF action in TRQ (Booking Request) when a condition satisfies in TOR (Manifestation). So we need a mechanism to trigger the PPF action configured in a BO via stand alone code.
字符串首字符索引为 0; Character Fields: C,N, D, T, string (CNDT=> CN Data Time)
email：lhui@hndldz.com & yuqishow@qq.com
今天特地整理了一份一二线城市知名的互联网（或者说IT相关）公司名单供参考。当然了，由于了解有限，难免会有疏漏和不当，也欢迎大家补充，众人拾柴火焰高。
笔者所在的D项目里，有工序委外场景，采购这边需要在SAP系统里输出PO FORM。在POFORM上需要将工序委外场景中发给供应商的子件物料号以及数量等信息显示在上面。
SAP The FM To Get the Characteristic Value
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
