SDK巨大漏洞

hmilyfwc

原帖由 eric_e 于 2010-1-4 18:16 发表
是正常的，如果你添加一个单据试试，系统不会重复的。
看一下“草稿”就知道了，里面单据号有多少都是重复的。呵呵。

系统逻辑和SDK逻辑不一致我在很多地方都看到过，但这根本都不是逻辑问题，如果SDK不提供oCompany.GetNewObjectCode(sSBO_No)此方法我也能理解,可既然提供了，却有这样的漏洞，我就不理解了。

hmilyfwc

原帖由 yatsea 于 2010-1-5 17:47 发表
对于网内会有一点影响，但是相比之下数据的完整性和一致性更重要。

最好的做法是，通过自己的业务逻辑来保证事务的完整性和一致性，比如在单据引入UDF记录是那个web用户创建的订单，
然后通过SQL查询根据用户找到对应生成的订单号，而不是通过oCompany.GetNewObjectCode(sSBO_No)

或者做一个MessageQueue来管理Web请求的DI操作，避免并发造成数据完整性和一致性的问题。

解决的方法还是有，无非是我不用SDK的oCompany.GetNewObjectCode(sSBO_No)方法，自己去数据库里检索，虽然要牺牲效率。

ferryfu

原帖由 hmilyfwc 于 2010-1-7 15:17 发表


      我不觉得我对b1不太熟悉，一直在做开发，从来就不会去考虑这种问题，因为觉得这么简单的问题SAP肯定能想到的，说实话这么大公司的产品如果真是这样，我确实不能理解。

B1让你不理解的地方很多很多的。
我做了这么多年都很多地方不能理解呢！！

eric_e

我觉得这个地方很容易理解的呀
单据在新增状态时会获取当前的编号，在添加时会重新到数据库中获取当前编号，在SDK也是这个逻辑，给那个接口，也只是让你获取当前的编号而已，如果同时有10个人在线同时做这种单据，大家有可能是相同的单号。

dijk

就是B1少做了一个trans lock，SBO是收购来的，并不是SAP本身开发的所以大家不要以奔驰的品质来看这个问题。

在系统内自加lock，影响效率，不加lock，有逻辑风险，所以终日生活在夹缝中的中东人把这个问题留给了用户，你想怎么就怎么吧，呵呵。开个玩笑。

其实R3里面都是lock的，但是通常上R3的硬件都很强所以都忽略了这个问题了。。。。
还有一个就是，这个号码本不该在此生成，而是保存的时候生成那么就不会有这个问题了，或者，点击生成的时候就自动占用-------敝人凭借R3 的经验随便说说呵呵

lorry15

本人也深受B1伤害~~~
同感顶下

ferryfu

经历过sdk开发的顾问，基本上都会对b1的sdk“深恶痛绝”。 也许sdk本身也需要不断的完善的。

eric_e

我也一样用SDK开发,但没有对SDK"深恶痛绝",尽管他有很多BUG,但毕竟给我们带来了很多方便.
我想说的,"编号"这个东西,SBO没有这个逻辑和原则上的问题,尽管我们可以通过transaction lock来实现锁定,但有没想法,如果用户打开个单据就离开了,难道你要一直锁着这张表吗? 我想R3和B1在基本逻辑上应该是一样的“添加时重新产生编号”。

dijk

SBO我不清楚，至于R3，其实用的也就是目前开发 的两种类型的序列号分配
1，保存时分配，就是你说的“添加时重新产生编号”。例如R3中的document number，Sales order number。
2，creat时分配，这个时候并不是一直lock这table，而是仅仅占用一个序列号，例如R3中的production order（配置为外部指定时）。