This content has been marked as final. Show 2 replies
I notice this in 220.127.116.11 as well - [http://www.mroshaw.co.uk/OllerenshawIT/index.php/2011/10/bip-and-siebel-8-1-1-5/] .
I've heard on the grape vine that 18.104.22.168 will fix a lot of stability issues with BIP Report integration. The eventual aim being to move all the Repository config required with ACR633 to move into the Business Service class code. Time will tell...
I looked a bit further into this white paper and the code behind it. There is at least one method argument (thankfully optional) incorrect. However, I have a wider concern on why they would discuss this as a way of replacing proposals without looking at non-scripting alternatives. I understand people may need a way to copy publisher documents as attachment (and may not want to use the undocumented FINS Industry BC methods) but for a typical "proposal replacement" the document would not need to be moved to the attachment objects it can remain in the Report Output BC.
This can be done entirely in declarative alternatives. I chose to extend the Report Output BC to contain parent row id (why on earth this is missing in the first place is beyond me) and duplicated the applets so we have in other business objects such as Case a search spec for the parent row id = ParentFieldValue(Id). The Report Output List Applet was also replaced with a modified search spec to not show where parent row id is populated so people cannot delete "Case Reports". The production of the report is of course slightly quicker since the copy/paste to attachment is not needed.
I cannot help but think Siebel came up short on this in the rush to get something out and I do appreciate the improvements in this release. I just hope, indeed expect, other developers to also look at other solutions and that the copy function is made available as hidden BS in a future release (as it is for FINS) but is an option rather than the basis. Give us the parent row id in vanilla Siebel!