在BPC75中，系统增加了很多用户自定义函数开发的接口，这其中就包括write back的BADI接口。当前，最新的BPC75NW的支持包是SP4，但是在75的前期版本中，都已经带有这个开发接口了。这个开发接口本身并不是强制要实现的。在没有实现write back BADI的前提下，我们依然可以可以通过正常的input schedule, data manager package, comment去向数据库发送数据。Write back BADI是在我们需要加强系统自带的写回功能时，需要执行自定义的逻辑时去实现的。
举一个按照Entity来做财务预算的例子说明，我们在Entity这个dimension上有一个层次结构，Worldwide是根节点，下面有亚洲、欧洲、美洲这几个子节点，然后再往下每个节点又有若干个国家的子节点。也就是说，在Entity这个dimension上，base level都是一些国家的节点。通常情况下，我们做预算的情况是，由每个国家的子节点输入数据，然后报表可以累加计算出top level的预算值，这是由于我们只能在base level的节点上post data。这是一个bottom-up预算的实例，但是我们不能做到反向，也就是top-down的预算流程。这种情况下，我们就可以通过实现write back BADI去完成一个分发的逻辑，将top level上面的数据值按照指定的算法分发到子节点上。比如在member的定义中，我们就可以专门指定一个属性去代表每一个member的分配权重，或者也可以根据去年同期实际数据做一个分发的逻辑。
再举一个复合的安全模型为例，在BPC的安全模型中，有一条基本的规则是，当dimension不同的安全规则叠加时，最小的限制条件起作用。我们有一个A的member access profile,设置如下：
Category = Plan Read/Write
Time = 2009.OCT Read/Write
Time = [ALL] Read
它的意图是要在plan这个category里面，用户可以查看所有时间的数值，但是只能写入2009.OCT这个时间区间的数值。同时还有另一个B的member access profile，设置如下：
Category = Forecast Read/Write
Time = [ALL] Read/Write 它的意图就是用户可以读和写forecast 里所有时间区间值。
如果上述的两个member access profile是分配给不同的用户是没有问题的。但是如果当他们被分配给了同一个用户的时候，就有会冲突了。管理员的意图是想限制在plan里面用户只能数据写到2009.OCT里面，但是当用户有了这两个member access profile以后，用户就可以写回数据到别的时间区间了，比如2009.APR。而这并不是管理员设计这样的安全模型的本意了。
在这种情况下，我们可以通过实现Write back BADI来处理。Write back BADI是一个pre-process BADI，它会在所有的BPC检查(security check,validation check,work status check)开始之前被调用。所以在调用安全模型检查之前，write back BADI就被调用到了。所以在这里我们可以根据需要，去绕过标准的安全模型。
顺便提下UJR_WRITE_BACK的filter参数，包括APPSET_ID,APPLICATION_ID,MODULE_ID，前两个是必须要有的，module可以是Manual planning, journals, data manager, comment, etc.
posted on
