Just for Information:
Not sure how many 11.1.1.6.0+ installs you all have out there, but BEWARE before you decide to head that route. In 11.1.1.6.x and above, there was a code change in the IPM to BPEL injector. The injector now injects a single Input Agent Session under a single ECID. Meaning, if you're polling the input directory, and there are 3 files, each containing 3 document, in BPEL you will have 9 instances, but ALL under the same ECID. There used to be a 1:1 relationship between a single IPM document and ECID. So when you attempt to look at the trace for the single instance, you will now be presented with a trace screen that has all 9 instances. This is because the trace portion of EM works off ECID. ECID is a blanket identifier that can be used to track an instance through it's lifespan throughout the Accelerator. As you know, instance ID changes as it moves from composite to composite. So now that all 9 instances injected into DocumentRouting all are now on the trace route because they all share the same ECID.
From a development/troubleshooting standpoint, this makes finding errors next to impossible. If you have a batch that's about 30 instances deep, when you see the faulted instance number and you click on it, you then have to dig through 30 TOP level instances (meaning DocumentRouting) then you have to dig down into each one to find the corresponding instance number. It doesnt just expand to the instance ID you clicked. It's a complete guessing game, and takes finding a fault from <1 minute, to now upwards of an hour.
Also, for those who have used the fact that ECID USED to have a 1:1 relationship with a single document in anything custom, well there goes that. We have developed custom composites that will create an 'Audit' PDF and file it away in IPM. This would query BPEL for the ECID's history, build it out in a nice readable format so they could see who approved, at what step, as well as dates. Now that ECID has however many instances beneath it, it's pretty much a worthless document as it contains history for all instance under that ECID.
I have since opened this up with Oracle, they have confirmed it's behavior, they did create a bug, but it has been slated to be addressed in 11.1.1.9.0....yes you read that right....11.1.1.9.0. This simply cannot wait that long. You might as well skip 11.1.1.6.0, 7, and 8 because this bug will ruin your day. Please, contact anyone you can, Bin Lang, your Oracle support team, perhaps a sales rep. Reference this bug number 16179892 and tell them you want a one off patch created. Believe me, once you move any of your customers to 11.1.1.6.0 (i've confirmed this bug exists in 11.1.1.7.0 as well), you simply will not want to deal with it. it essentially makes EM unusable. If we raise enough of a stink, this will get fixed. And i can't imaging it being anything that would take too long to do. they simply need update the injector BACK to the way it was working. HELP FELLOW WEBCENTER IMAGING-ERS
9 Views
Not sure how many 11.1.1.6.0+ installs you all have out there, but BEWARE before you decide to head that route. In 11.1.1.6.x and above, there was a code change in the IPM to BPEL injector. The injector now injects a single Input Agent Session under a single ECID. Meaning, if you're polling the input directory, and there are 3 files, each containing 3 document, in BPEL you will have 9 instances, but ALL under the same ECID. There used to be a 1:1 relationship between a single IPM document and ECID. So when you attempt to look at the trace for the single instance, you will now be presented with a trace screen that has all 9 instances. This is because the trace portion of EM works off ECID. ECID is a blanket identifier that can be used to track an instance through it's lifespan throughout the Accelerator. As you know, instance ID changes as it moves from composite to composite. So now that all 9 instances injected into DocumentRouting all are now on the trace route because they all share the same ECID.
From a development/troubleshooting standpoint, this makes finding errors next to impossible. If you have a batch that's about 30 instances deep, when you see the faulted instance number and you click on it, you then have to dig through 30 TOP level instances (meaning DocumentRouting) then you have to dig down into each one to find the corresponding instance number. It doesnt just expand to the instance ID you clicked. It's a complete guessing game, and takes finding a fault from <1 minute, to now upwards of an hour.
Also, for those who have used the fact that ECID USED to have a 1:1 relationship with a single document in anything custom, well there goes that. We have developed custom composites that will create an 'Audit' PDF and file it away in IPM. This would query BPEL for the ECID's history, build it out in a nice readable format so they could see who approved, at what step, as well as dates. Now that ECID has however many instances beneath it, it's pretty much a worthless document as it contains history for all instance under that ECID.
I have since opened this up with Oracle, they have confirmed it's behavior, they did create a bug, but it has been slated to be addressed in 11.1.1.9.0....yes you read that right....11.1.1.9.0. This simply cannot wait that long. You might as well skip 11.1.1.6.0, 7, and 8 because this bug will ruin your day. Please, contact anyone you can, Bin Lang, your Oracle support team, perhaps a sales rep. Reference this bug number 16179892 and tell them you want a one off patch created. Believe me, once you move any of your customers to 11.1.1.6.0 (i've confirmed this bug exists in 11.1.1.7.0 as well), you simply will not want to deal with it. it essentially makes EM unusable. If we raise enough of a stink, this will get fixed. And i can't imaging it being anything that would take too long to do. they simply need update the injector BACK to the way it was working. HELP FELLOW WEBCENTER IMAGING-ERS
9 Views
No comments:
Post a Comment