Redesign and bugs fix of SRM Classic Transfer

今天发现个NOTE..2010年8月底出的.

从SRM7.0 SP10开始,SRM Classic Transfer的逻辑有重大变化.

 

首先,确保1342152已经打上[700 SP04, 500 SP16自动附带],该NOTE确保了BBP_GET_STATUS_2使用了正确的上锁机制.

 

逻辑变化总结:

1. Creation of backend documents in the backend system and updating of the SRM related data to these documents is now done in one synchronous step.

(说的太模糊,应该是指购物车从此开始同步更新.参考第二点)

 

2. The "Cleaner" (report "CLEAN_REQREQ_UP") is no longer responsible for Shopping Carts, however the report still needs to be run as a job to handle all other types of documents!

(CLEAN_REQREQ_UP不再对购物车起传输作用, 购物车应该走同步的道路了. 在ECC使用FM BAPI_TRANSACTION_COMMIT, 现在这个FM发出"Commit Work and Wait".一旦RFC从ECC返回,SRM则会验证是否提交成功,如果成功,SRM端会读取ECC发来的文件信息,同步SRM与ECC,而这些都是以前CLEAN_REQREQ_UP干的活)

 

3. Shopping carts for which the creation of the backend documents failed (e.g. R/3 kernel dump, ABAP dump, Backend unavailable) will, if possible, be picked up automatically and retransfered automatically.

    -  This works for both local and classic scenario as long as the shopping cart is "In Approval".

    -  Once items are "In Transfer" only classic items are processed.

(将有后台作业自动查找那些传输到ECC失败的购物车,然后再次传送.此方法对购物车状态为"待审批”且为local, classic的业务场景有效.对购物车状态为"传输中"且是classic的业务场景也是有效的.)

 

4. The new report "BBP_SC_AUTO_RETRANSFER" is responsible for handling any failed transfers. The report has to be scheduled as a job and run e.g. once every hour (but not more often than every 15 minutes). In case of multiple failures items will get status "Error in Transmission" and administrator will be notified via Alert Monitor. By default, any Shopping Cart with a "Changed At" timestamp on Header Level of the Shopping Cart from within the last 48 hours will be checked. Once 24 hours are exceeded, the Shopping Cart / it's Item(s) are set into an error state and the administrator is notified. These two parameters can be adjusted.
Additionally the "Changed At" timestamp must be at least 15 minutes before otherwise the Shopping Cart is also excluded.

(BBP_SC_AUTO_RETRANSFER就是这个新开发的后台作业.建议每小时运行一次但频率不要低于15分钟.对于状态为"传输错误"的购物车,系统管理员会收到提醒.检查范围:查找购物车header层中"Changed At"字段的时间章.范围是系统时间的15分钟后 到 48小时内.一旦传送失败的购物车超过24小时,也会被设错误状态发送给系统管理员.)

举例:

A:一个购物车在一小时前更新. 然后传输失败了. BBP_SC_AUTO_RETRANSFER会选择该购物车进行重新传输.如果传输仍然失败, 而"Changed At"也没有变化,则23小时后,该购物车会被设成"错误"的状态并发给系统管理员.

B:一个购物车在30小时前更新.传输失败.在此期间,BBP_SC_AUTO_RETRANSFER并没有运行.该购物车会被设成"错误"的状态并发给系统管理员.

C: 一个购物车在49小时前更新.在此期间,BBP_SC_AUTO_RETRANSFER并没有运行.该购物车将不会被发现.

注意:有参数可以控制48小时这个默认指.(还有个参数是什么?)

 

5. Items from Sourcing Cockpit that are transfered into the backend system will have the status "In Transfer" along with the "source_rel_ind" flag of "X". These items are no longer visible in the Sourcing Cockpit until the item has been transfered completely. In case the transfer failed in such a way that the backend document could not be created, the item is sent back to the Sourcing Cockpit. If the backend document was however
created, the SRM data is updated accordingly.

来自于Sourcing Cockpit的购物车行项目会被设为"传输"状态,"source_rel_ind"标记为"X". 这些行项目在Sourcing Cockpit中将不会再显示.但如果传输失败的话,这些行项目还是会被发回到Sourcing Cockpit. 当然如果ECC端对行项目有更新,SRM端的数据也会相应更新.

 

6. Critical code spots where any failure is unexpected and should never happen will cause the entire process to dump (e.g. any "commit work and wait" in this process fails).

 

New code execution flow for Classic Transfer (rough overview):

a) Get a lock on the Shopping Cart item using BBP_PD_SC_LOCK and use "no dequeue on commit" protection

b) Filter the items from the shopping cart (e.g. SoCo items)

c) Determine follow-on document type and number

d) Update BBP_PDBEI table with Object ID and Type, clear Item number. Set status I1111 ("In Transfer") to active and deactivate I1112 ("Error in transmission") in CRM_JEST table. "Commit work and wait"

e) Update BBP_PDBEI table with Object ID, Type, Item number. "Commit work and wait"

f) Create document in Backend (BAPI_*_CREATE) and evalute the return

g) Issue "BAPI_TRANSACTION_COMMIT" in Backend with "wait" parameter and evaluate the return

h) Read document from the Backend

   -  In case of success: Update BBP_PDBEI table with Object ID, Type, Item number, Introw, Packnow. Update item and header relations. Set status I1113 ("Transfered") and deactivate I1111 ("In Transfer") in CRM_JEST table. "Commit work and wait"

   -  In case of failure: Retry the reading 15 times (required due to note 187687). In case of continued failure set status I1112 and deactivate I1111, send an alert to the Shopping Cart Monitor. "Commit work and wait"

i) Unlock the Shopping Cart

 

Consequences:

o  The new report "BBP_SC_AUTO_RETRANSFER" has to be scheduled as a job

 

o  Items which were processed within the sourcing cockpit will be removed from it until the "BBP_GET_STATUS_2" job is run again

 

o  On Header Level of the Shopping cart the fields "CHANGED_AT" and "CHANGED_BY" are updated when the report "BBP_SC_AUTO_RETRANSFER" was able to process shopping cart items in some way.

 

o  In case customer code relies on these fields it has to be analyzed how this change affects the customer code.

 

o  Upon creation of the backend document SRM validates that the document will (probably) be created successfully (no error messages are returned upon calling "BAPI_PO_CREATE" for example). If this is the case, the Function Module "BAPI_TRANSACTION_COMMIT" is called in the backend. Unlike before however, this Function Module will now issue a "Commit Work and Wait". Once the RFC returns from the backend, SRM now validates that the commit was successfull and, if so, reads the document from the backend and synchronizes the SRM data with the Backend Data (this was done by CLEAN_REQREQ_UP before which would run as a job up to several minutes later).

 

o  The item status for each document (stored in table CRM_JEST), "In Transfer" (I1111), "Error in Transmission" (I1112) or "Transfered" (I1113) as well as the corresponding backend documents (table BBP_PDBEI) are written as soon as the backend data (e.g. backend document number) is known and is commited immediately.

 

o  In case customer code relies on the data in "CRM_JEST" and "BBP_PDBEI" table customer has to analyze how this affects the customer code. The old code would set the BBP_PDBEI entries after creating the document in the backend. Therefore it is important to check the item status for I1113 to know if a follow-on document actually "exists", and as multiple documents can be created out of one single shopping cart item (via SoCo) the item relations may also need to be checked.

 

o  In case any customer modifciations have been done in "CLEAN_REQREQ_UP" coding concerning Shopping Carts, this code has to be moved into a different code section (method "UPDATE_BE_FIELDS"). This methode is a combination of the former "WRITE_CLEANER_INFO" and the "CLEAN_REQREQ_UP" code.

 

o  Customer coding must use proper locking mechanisms to ensure data integrity. For Shopping Carts, "BBP_PD_SC_LOCK" must be executed using the proper scope ("no dequeue on commit" parameter may need to be used along with "BBP_PD_SC_UNLOCK") throughout if some external job/report conducts changes to any Shopping Cart.

 

o  Customers must pay close attention to the "UPD" processes on the SRM System! Due to the code changes which use "commit work and wait" more often, the "UPD" processes can take longer than before. This could in turn cause "UPD" processes to be queued longer than before. Increasing the number of "UPD" processes may
be required.

 

SAP Note: 1499352