Business Function Processing Problems
A-2
JD Edwards EnterpriseOne Tools Configurable Network Computing Implementation Guide
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.
A.1.1 Failure to Connect to the Server
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
A.1.1.1 Failure to Connect to the Server in a Non-Clustered Server 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:
1.
The user calls a business function on a server.
2.
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.
3.
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.
4.
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:
1.
If the business function runs without error, either on the original server or the
failover alternative, the request has been processed.
2.
If the client workstation request is not successfully processed by the server, the
software increments a reconnect counter and attempts one reconnection.
3.
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.
4.
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.