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
Originally a Physics major, fell in love with Microprocessors and switched to Computer Science 20+ years ago. Since then, dabbled in various languages including, PowerBuilder, Oracle, Java, C, C++, Perl, Python etc. Constantly striving for quality and performance too.
I try to help fellow developers with technology as a way of "giving back to the community". Blogging became a natural extension of that effort. Still learning to perfect that art. If one new programmer out there benefits from this blog, my time and effort are fully worth it.
The underlying theme in my blogs is power and beauty of programming (and technology in general). A well written program gives me the sense of awe you get when you look at a man made wonder like Angkor Wat. You experience poetry, art, mystique, power all at once. A program and the troubleshooting that ensues also gives you a feeling you get while reading a mystery novel!
Submit an article or tip
