Sunny - best to not reply to Forum Posts with private messages. To enable others to help I've included your response below:
------------------------------------------------------------------------
Sunny48 said:
1. Tell us how you know that UBE wasn't called. Does the UBE show up in Submitted Jobs?
UBE does NOT show up in Submitted jobs. I want it to run interactively.
On fat client, it calls UBE. I changed OCM to run UBE locally on my fat client.
But on Server it does not call UBE.
2. This sounds like a very strange process. Are you expecting data to be returned to the NER / App from the UBE?
Yes, I am expecting data to be returned to Application from UBE. UBE is genearing a data in my working file.
---------------------------------------------------------------------------------------------------------
OK - you need to learn some things about JDE.
In a Web environment UBEs do not run locally or interactively. They are also not synchronous when called from a BSFN or Application. You may submit/call a UBE but the App/BSFN won't wait for the UBE to complete.
From Oracle Doc 626500.1:
--------------------------------------------------------------------------------------
The definition of synchronous means to run the UBE in my process space and wait for its return value. This is not possible when the UBE is launched from an interactive application to the server. This is only possible when the UBE called from an interactive application is run locally. Therefore, whenever a UBE is called from an interactive application and run on the server, it will always run asynchronously.
Release Xe and 8.0
In releases Xe and 8.0, a synchronous call to a UBE is allowed in a business function mapped to the server. However UBEs are not meant to be submitted in this manner as there is a potential performance issue in that the Call Object kernel can be tied up if the UBE runs for an extended period of time. The recommendation is that UBEs called from a Business Function should be submitted asynchronously.
Release 8.9 and above
Starting with release 8.9, a synchronous call to a UBE in a business function mapped to the server is no longer allowed. When a UBE report is called synchronously in a business function (called by itself or in a parent business function) mapped to the server, a UBE message is written in the Call Object Kernel log: "Error UBE0000007: attempting to call Report and Version synchronously from within a CallObject Kernel", the report will not launch and no record is written to the Job Control Master table F986110.
If the design of the business function requires that UBE must complete before executing the remaining business function code after the call to the UBE, there is a possible workaround solution to monitor the completion of the UBE through the use of the Job Number of the Submitted Job after the UBE has been submitted asynchronously using API jdeLaunchUBEEx. Use the job number returned by the API to query the Submitted Jobs table (F986110) to continually check the job status of the UBE until either D (Done) or E (Error) or for the desired amount of time. When the UBE job status is Done, execute the business function remaining code after the call to the UBE. Otherwise, take the appropriate action that the UBE did not run successfully.
A synchronous call to a UBE in a business function running outside of the Call Object kernel is still allowed. For example, a business function called in a UBE can call a report through synchronous report interconnect provided business function and UBE that calls the business function are running on the same server. If the business function, containing a call to a synchronous report interconnect, must run on the server, the workaround is to call the business function within a driver UBE and run that UBE on the server.
-----------------------------------------------------------------------------------------
Did you LOOK on the Submitted Jobs screen to see if your UBE was there?
Avoid application architectures that may have a user waiting on a UBE to populate data which in turn is waiting on batch queue availability.