This appendix contains the following topic:
The Oracle JD Edwards EnterpriseOne configurable network computing (CNC) solution enables developers and administrators to map business functions to one or more application servers for logic processing. When a problem occurs on the server, the software attempts to reconnect to the application server so that the business function can run. If the software can reconnect to the server and run the business function, work proceeds uninterrupted.
However, these circumstances can complicate business function processing:
The client workstation cannot reconnect to the application server because a server process has died.
Business function processing creates cache, or state information, on the application server whose process has died.
The business function causes one or more processes to die on the server.
The client workstation cannot reconnect to the application server because the server machine has gone down and the server machine is part of a server cluster.
When the client workstation cannot communicate with the server, the software redirects business function processing to a secondary server. A list in the CallObject code designates the name of the original server and the name of the secondary server to which future calls should be rerouted.
Note:
The default configuration is that no secondary server is defined during the JD Edwards EnterpriseOne installation process. Defining a server will require changes to the OCM mappings. If you do not define a secondary server and failover occurs, the software remaps business function processing from the failed server to the client workstation.When business function processing creates cache on the application server where a process has died, the client workstation reconnects to the application server, but the user must exit the application and restart it.
When a business function causes one or more processes to die on the server, the client workstation reconnects to the server. Because the business function is causing the jdenet_k process to die, JD Edwards EnterpriseOne fails the business function call.
When the client workstation cannot communicate with a server in a server cluster, the software recognizes that the server is part of a cluster and continues to try to reconnect. The transfer of control from one server in a cluster to another server in a cluster can take several minutes.
The JD Edwards EnterpriseOne Configurable Network Computing solution provides a methodology that handles business function failure and enables you to continue working, even when a server has failed or a kernel process has died, ending the processing of logic on an application server. In addition, the software writes a message to the jde.log whenever a failover occurs, enabling you to troubleshoot the problem.
The mechanism by which a business function fails to connect to a server depends on how the server is configured in the network. Failures for these two types of configurations are discussed in this section:
Failure to connect to a server in a non-clustered server configuration
Failure to connect to a server in a clustered configuration
In a non-clustered server configuration, the software redirects business function processing if it cannot connect to the primary server. These steps describe what occurs during the initial stages of an attempt to call a business function to run on an application server:
The user calls a business function on a server.
The software checks to see if the server has been failed over from the primary server to a secondary server or to the client workstation.
If processing has been directed to another server, the software remaps the business function and sends the CallObject message to the secondary server or to the client workstation to run the business function.
If the server has not been failed over, the software sends the CallObject message to the original server to run the business function.
In the second phase of business function processing, the software attempts to run the logic on the application server or client workstation. These steps describe what occurs during the second stage of processing:
If the business function runs without error, either on the original server or the failover alternative, the request has been processed.
If the client workstation request is not successfully processed by the server, the software increments a reconnect counter and attempts one reconnection.
If the value on the reconnect counter is greater than 1, the business function fails. If the value on the reconnect counter is not greater than 1, the software reconnects to the server and attempts to run the business function.
If the client is unable to reconnect to the server, the request is redirected to a secondary server if one is defined, or to the client workstation if one is not defined.
If cache has been created on the server, the user must exit the application and restart it.
If a business function fails because of a server failure in a clustered configuration, rather than failing over to a secondary server or the client workstation, the client will wait until a new machine in the cluster is available then resubmit the business function request. While trying to reconnect, the software displays a transient window: This window refreshes once a minute and continues to display until the client is able to successfully reconnect to the clustered server.
If the business function cache was created on the first server before it went down, the software will not submit the business function request to the server cluster. In this case, you must exit the application and then resubmit the business function.
When a client workstation requests to run a business function on a server, the server must successfully load the business function before it can run. This process can fail for these two reasons:
Server cannot load the library where the business function resides.
Server cannot get the address of the business function.
When the server cannot load the business function library, the software displays this message on the client workstation and writes the text of the message to the jde.log file on that machine:
The Business Function Library xxxx could not be loaded on server yyyy. Because of the unknown cache-state on the server, you must exit this application all the way to the menu. Please notify your JD Edwards EnterpriseOne System Administrator to have the problem corrected before attempting to run the Business Function zzzz again.
Probable reasons that the library failed to load are that:
The business function library failed to build during the package build process.
The library was inadvertently deleted or renamed.
A problem exists with permissions.
If the library fails to load, close the application until you get to the menu, and contact your system administrator. Ensure that the problem is corrected before you attempt to re-run the business function.
When the server cannot get the address of the business function within the library, the software displays this message on the client workstation and writes the text of the message to the jde.log file on that machine:
The Business Function xxxx was not found in the Business Function Library yyyy on server zzzz. Because of the unknown cache-state on the server, you must exit this application all the way to the menu. Please notify your JD Edwards EnterpriseOne System Administrator to have the problem⇒ corrected before attempting to run this Business Function again.
Probable reasons that the server cannot get the address of the business function are that:
The package build process failed to create the module that contains the business function; therefore, the module was not included in the business function library.
The client has a newer package than the server, and the business function exists on the client but not on the server.
If this error occurs, close the application until you get to the menu and contact your system administrator. Ensure that the problem is corrected before you attempt to re-run the business function.
The business function itself can cause one or more processes to die on the server. In this case, the software displays a dialog box indicating that the business function is causing problems.
You might have to change OCM mappings or fix a bug in the business function if this dialog box appears.
If the business function does not run the first time, the software checks to see if cache was created on the server during the first failed attempt. If no cache is created and the reconnection attempt to the primary server fails, the software attempts to run the business function on the secondary server or the client workstation.
If cache is created on the server, the software instructs the user to close the application and start over. This message is also written to the client jde.log file.
The creation of cache on the server is vital to the processing of business functions. The software creates cache when one business function runs so that one or more subsequent functions can use the data in the cache. For example, one business function might create and initialize the cache, a second might add data to it, and a third might access the data and insert it into a database.
If a process on the server dies after the first business function creates the cache and the client workstation is unable to communicate with the process on the server that contains the cache, the subsequent business functions are not able to access the original cache. Therefore, in this scenario, the software forces you to close the application and start over.
Note:
UBEs and table conversions continue to process business functions after a failure, even if they create cache on the server.