When you work on code deployed to n-tier, you have to be little more careful while defining the interface for the objects. An n-tier application typically runs in a heterogeneous environment, meaning objects in different languages/platforms may talk to each other through a common interface. If you are not careful, your object may end up being passed to the wrong tier that doesn’t know how to interpret it. You have to make sure the data types of the interface functions exist on all sides. Otherwise, you will get unexpected errors at compile or run time.
This is true for PB also, if you are deploying your code to EA Server. Mixing system objects and types in the object’s interface will cause errors while deploying to EA Server as shown below.
1. CORBA IDL Error on PB System objects
While deploying this project (p_d_adm_roles_lh) to EA Server, PB throws the following error message:
---------- Deploy: Deploy of p_d_its_adm_roles_lh
Doing Incremental Rebuild...
Generating IDL for Selected Components...
Generation Messages:
Deployment Warning: SYSTEM Variables Not Supported. The following bypassed for component 'im_adm_roles_impl': n_txn
Deployment Warning: SYSTEM Variables Not Supported. The following bypassed for component 'im_adm_roles_impl': n_txn
---------- Finished Deploy of p_d_its_adm_roles_lh
Here is what Sybase document says:
Deployment error or warning (from PowerBuilder): SYSTEM variables not supported
Public instance variables and arguments to public functions can be any of: Standard datatypes, Structures, Custom class user objects that have been deployed as EAServer components, ResultSets.
If you are using system datatypes (transaction, data store, and so on) as instance variables, declare them as protected or private.
If you are using system datatypes as function arguments, declare the function as protected or private.
The real problem was in the CORBA interface. I declared a public instance variable called n_txn of type Transaction which is known to PB but not to CORBA IDL (interface definition language). So, this cannot be in the public interface of the object. CORBA IDL only allows types that can be mapped to it’s own. User defined objects are allowed, as long as they themselves are composed of simple types that IDL allows. More on these in a separate post.
While deploying a component to EA Server, PB generates IDL and related proxy and stubs/skeletons for the CORBA interface. It checks to make sure generated IDL complies with the rules of IDL definitions. In the above example since PB’s Transaction object cannot be mapped to any IDL type, PB prevents deployment and throws the error. Thus avoiding surprises at runtime.
Ideal solution is to avoid non-standard types in the instance/shared variables in objects to be deployed to n-tier. But, if you really have to define instance/shared variables of types that are not translatable to IDL, then make them private or protected. IDL interface is generated only for the public attributes and methods.
References
