Kbase P73225: Troubleshooting Open Client Problems
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/04/2009 |
|
Status: Unverified
GOAL:
Troubleshooting Open Client Problems
GOAL:
How to troubleshoot Open Client issues
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
FIX:
This document applies to: Progress Open4GL
Version and Release Number: 9.x and higher
Progress Open4GL provides a way to access 4GL programs running on the
Progress AppServer from Java and ActiveX clients.
Because This scenario involves Progress products and code as well as third-party
products, it can be difficult to determine where the problem lies, and
whether an issue can be addressed by Progress, as opposed to one which
is strictly within the non-Progress client code.
The steps outlined below are provided as guidelines in identifying and
isolating Open Client problems, i.e., problems encountered when trying
to run Open Client code, in the test stage of the development cycle or
upon deployment. This assumes that no errors were encountered when
compiling any code being used, or generating any proxies used by the
Open Client.
I. Verify Configuration
This can be done with one of the 'roundtrip' tests included on the
media (version 9.1x and above) as part of the Open Client Toolkit.
There are two versions of this test: one to test the configuration for
Java clients, and one to test the configuration for ActiveX clients.
These tests will be installed in dlc\java\techsupp\java and
dlc\java\techsupp\activex, respectively, and should be delivered to
the client machine along with the deployed application.
If the roundtrip test is successful, this verifies that the
configuration is correct for communication from the Open Client to the
database and from the database back to the Open Client.
II. Isolate problem: Server Side vs. Client Side
Assuming the configuration has been verified, the next step in
diagnosing an Open Client issue is to investigate any runtime errors
that occur, and to examine all available logs (server-side logs are
covered in the AppServer documentation; Open Client runtime errors and
error logging are covered in the Open Client documentation).
If the problem is not apparent and self-explanatory from these errors
and/or logs, it will be necessary to conduct tests as outlined below
to isolate the problem.
1. Server Side
The first step in a test of an Open Client issue would be to run the
AppServer code from a 4GL client.
If the AppServer code includes SmartDataObjects (SDOs), the 4GL client
in this case requires special attention. SDOs run on an AppServer from
a 4GL client are ordinarily run from a Smart Client. Since the
functionality of a Smart Client is not present in a non-Progress
client, that functionality should not be present in the 4GL client for
this to be a valid test. Progress supplies sample code for running an
SDO directly from the 4GL, and documentation on running SDOs from Open
Clients. This is installed with ProVision in directory
dlc\src\samples\open4gl\sdo.
If the problem occurs when the AppServer code is run from a 4GL
client, then clearly there is a problem on the AppServer side of the
interface (rather than with the Open Client, the Open Client Runtime
product, or the proxy). The issue can then be investigated as would
any AppServer issue.
2. Client Side: Generated Proxies and Their Usage
If the above test is inconclusive, the problem may be within Open
Client Runtime, in the generated proxies, with the usage of the
proxies by the client, or isolated within the client itself.
The most basic test here is to run simplified Open Client test code
which does little or nothing more than call the proxy methods. This
will eliminate all extraneous parts of the client code, exercising
only the proxy's functionality in concert with the Open Client Runtime
product. If the problem is still. evident with this test, but the
cause is not obvious to the customer, Tech Support can assist in
interpreting the results.
This assumes that the client code is using correct syntax in calling
the proxy's methods. Tech Support can provide assistance regarding
how to use methods common to all proxies, which are part of the
Open Client interface, but cannot provide code examples or coding
assistance for every type of client, or assistance with the specifics
of interacting with any given 4GL application. (Note: For test
purposes, the 4GL can be used as an ActiveX client, accessing the
proxy as it would any COM object. See the External Programming
Interfaces manual for more information on this topic.)
If the problem is still not evident, the problem could be with the
proxy itself. At this point Tech Support may provide additional
instructions to examine the proxy, or may request the minimal 4GL
AppServer code used in the above test, not to run, but to use to
generate proxies in-house and examine the results.
3. Client Side: Open Client Runtime
If the problem still occurs in the simplified test scenario described
above, and there is no obvious problem with the proxies, the problem
could lie in the Open Client Runtime product itself. To determine
this, Tech Support would need to reproduce the problem in-house as
outlined below.
III. Submitting Code to Tech Support to Reproduce an Open Client Issue
If at this point, the source of the problem is still not evident, or
if the problem appears to be within the Progress portion of the
interface, it will be necessary for Tech Support to reproduce the
problem in-house. To do this, we need from the customer:
1. A simplified version of the 4GL code run on the AppServer,
containing only enough code to reproduce the problem. As with all
code samples submitted to Tech Support, this code should be written
against the sports database or the sports2000 database if at all
possible.
2. Proxies generated from the above code.
- For Java clients, the proxy .class files and public Application
Object .java files
- For ActiveX clients, the proxy .DLL and .TLB
3. Simplified Open Client test code which does little or nothing more
than call the methods in the proxy, for illustration only.
- For Java clients, the client .class files
- For ActiveX clients, the executable
For both of the above, Tech Support may request the client source
code to use as a point of reference to facilitate testing. If at
all possible, ActiveX client code samples should be written in 4GL,
VB, or C++. A problem anywhere within the Progress portion of the
ActiveX client-to-Progress interface should be reproducible from
any type of ActiveX client.
If Tech Support can reproduce the problem using the customer-supplied
client code, but not with our own client code which accesses exactly
the same proxy methods, then the problem is external to the Progress
Open Client interface.
The one exception to this rule would be the case where there is a
problem in the client code, but the issue is with Progress' handling
of the error. In this case, Tech Support will require the client
source code with the error in the client code clearly identified.
Once a problem has been identified as a Progress issue as outlined
above, Tech Support will work with the customer, and with Progress
Development if necessary, to reach a resolution..