Consultor Eletrônico



Kbase P71221: What Are SmartDataObject Proxy (_cl) Files?
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   1/27/2011
Status: Unverified

GOAL:

What Are SmartDataObject Proxy (_cl) Files?

FIX:

SUMMARY:

This solution applies to Progress Version 9.0A in a Windows
environment. It describes the purpose of SmartDataObject (SDO)
proxies and how they are used with open clients and testing/deployment
issues.

EXPLANATION:

SDOs theoretically have three parts:

- Frontend portion:

Communicates with visualizations (SmartDataViewers and
SmartDataBrowsers) and does not need to be connected to a
database.

- Backend portion:

Communicates with the database to perform updates and must
be connected to a database.

- Communication portion:

Handles communication between the frontend and backend
portions of the SDO.

SDO proxies are a version of an SDO that does not contain code to
access the database (backend portion). When an SDO is created for the
Customer table for example, the following files are generated by the
AppBuilder (regardless of the remote/local configuration for the
partition this SDO runs on):

dcust.w (Full SmartDataObject)
dcust.i (RowObject definitions)
dcust.r
dcust_cl.w (Client proxy)
dcust_cl.r

dcust_cl.w contains the following code:

/* dcust_cl.w - non-db proxy for dcust.w */

&GLOBAL-DEFINE DB-REQUIRED FALSE

{dcust.w}

The DB-REQUIRED parameter is used to determine whether the code that
accesses the database (query definitions), and any code that you
choose to make DB-Required from the Section Editor, is to be compiled
into a version of the SDO. Use of DB-REQUIRED makes the client proxy
version of the SDO streamlined because it does not include code that
accesses the database.

In the above example, dcust_cl.w is the same file as dcust.w without
the backend portion that communicates with the database.

An SDO can run in three three modes:

- Local:

The full SDO will run locally connected to a Database
(dcust.w).

- Remote with proxy on client:

The proxy SDO (dcust_cl.w) runs on the client and the full
SDO (dcust.w) runs remotely on an AppServer. This happens if
the partition is configured to run remotely and the client
is not connected to the database at runtime.

- Remote with full SDO on client:

The full SDO runs on both the client and AppServer remotely.
This happens if the partition is configured to run remotely
and the client is connected to the database at runtime. The
decision to use the full SDO or the client proxy version is
based on whether or not the proper databases are connected
(independent from the decision to run remotely or locally).
Because the partition is an instance property of the SDO,
only after start up of the SDO (or its proxy) is it
determined which partition is to be used and whether or not
it is to be executed in a local or remote fashion.

Your SDO should run the same way whether you are running the
proxy version or the full version, but the full version
includes more code that is not executed by the client in a
remote configuration.

Any test of your SDO application with the AppBuilder is
always a test of the full version of the SDO on the client
because in design mode, an SDO must always be connected to a
database. This means that the full version, not the proxy
version, is run. Before deployment, test your proxy version
of the SDO from the Procedure Editor after you first
disconnect from the database.

If you intend to use SDOs with open clients, that is,
running them on an AppServer as the business logic for a
Java or ActiveX user interface, you must use the full SDO
(not the SDO client proxy _cl file) with ProxyGen to
generate the open client proxy.