Bob Wade
Member
We are running E1 8.10 Tools 8.94 on a "multi-tiered" configuration. The database is on iSeries, Websphere 5.0 is running on Intel servers, all logic (Call Object, UBE, Security, Scheduler, XML, etc kernels) runs on a number of Intel servers. There are multiple Web Servers, load balanced via network switches, each with a dedicated Application Server (running Call Object kernels for associated Web Server).
We have encountered an issue with any BSFN that uses the jdeLaunchUBEEx function to launch a UBE. Apparently (according to Oracle), by design the UBE will only launch on the same server that is running the BSFN executing the jdeLaunchUBEEx function. It ignores the DEFAULT BSFN OCM mapping. This results in unpredictable performance of the interactive BSFN calls for the Web Client users because of the mix of Call Object kernels and UBEs on the same server. We are trying to get the UBEs to run on one of the Logic Servers designated for Batch (UBE) jobs.
The problem was first noticed in Payroll, however, we have identified 88 BSFN that use jdeLaunchUBEEx of which 33 may be a potential problem for us.
This issue would probably not exist on a single tier architecture and does not exist with Terminal Server clients (when BSFN are mapped locally).
Has anyone encountered this problem and found a workaround?
We have encountered an issue with any BSFN that uses the jdeLaunchUBEEx function to launch a UBE. Apparently (according to Oracle), by design the UBE will only launch on the same server that is running the BSFN executing the jdeLaunchUBEEx function. It ignores the DEFAULT BSFN OCM mapping. This results in unpredictable performance of the interactive BSFN calls for the Web Client users because of the mix of Call Object kernels and UBEs on the same server. We are trying to get the UBEs to run on one of the Logic Servers designated for Batch (UBE) jobs.
The problem was first noticed in Payroll, however, we have identified 88 BSFN that use jdeLaunchUBEEx of which 33 may be a potential problem for us.
This issue would probably not exist on a single tier architecture and does not exist with Terminal Server clients (when BSFN are mapped locally).
Has anyone encountered this problem and found a workaround?
