STEPLIBs for the Natural RPC Server

I was wondering how other sites using EntireX to expose Natural objects via various integration methods (e.g., as a SOAP-based web service for example) handle this scenario.

The Natural RPC Server has a default library it runs in, and we created a library called WS-LIB which only serves to be the home library. However, the exposed objects can be in any number of different application libraries, and our approach has been to add the libraries these modules reside in as STEPLIBs of WS-LIB so the Natural RPC Server can find them.

There is a limitation to this approach as the number of STEPLIBs is limited to 8 or 9. Experience holds that I need some FNAT STEPLIBs anyway for this to work, such as SYSIDL, SYSRPC, SYSLIB and SYSLIBS, so that leaves 4 libraries for application code to be exposed. We have many more than 4 application libraries, so how can we set up the Natural RPC Server so that it will be able to be used to run exposed Natural subprograms regardless of the application library it resides in?

It would be nice if somehow the library name from the IDL/XMM definition was used so the XML RPC server would log on to that library to execute the code. If there is a way to do that, it sounds like the preferable way to go.

Thanks in advance!

-Brian

Hi Brian,

I assume you’re talking about the XML/SOAP Listener, because this one calls Natural subprograms.

That should work once you set exx-natural-security=true (the parameter name is a bit misleading…) in the Listener configuration.

See also the documentation of the Natural RPC Server:
http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat826mf/rpc/oper.htm#oper_rpc_logon2server_lib

Just forgot to say that you can explicitly set the Natural library name in the configuration using exx-natural-library.

Thanks, Rolf! I will research that setting for exx-natural-security=true and give that a try.

I found Empower KB article 1702642 which provides more detail on this matter.

I wasn’t sure until I checked that how the parm was set.

Hello Sagi,

Thank you very much for looking into the request.

Could you please post this as a reply to this forum topic STEPLIBs for the Natural RPC Server (you can also use the Reply link directly) – this way it will reach Brian Johnson directly and will be available to the whole community

Best regards,
Tech Community Team

From: Achituv, Sagi
Sent: Wednesday, September 28, 2016 6:15 PM
To: TechnologyCommunity
Subject: RE: Tech Forums >> EntireX >> STEPLIBs for the Natural RPC Server

Hello Brian,

Here are my 2 cents on this subject:

  1.   Check for the Natural RPC parameter called "logon required" – as I think it might lead you to what you were asking for, but  I currently do not remember if it has pre-requisites , mainly in the client application side
    
  2.   Most of the "sys*" libraries that you have mentioned are required when using the Natural RPC Server to perform IDL Extraction or generation, -
    

so we have a dedicated RPC server for this purpose, with all these libraries as steplib , while for all the other servers – we ignore them

Hope that helps

Sagi Achituv

Hi,

  1. Natural RPC parameter “logon required” has dependencies to RPC clients: The RPC clients require to set “Natural Logon”. If not set on the RPC client side the RPC request does not work. For XML/SOAP Listener this is done with “exx-natural-security=true”. Other RPC clients (Java Wrapper, Net Wrapper, COBOL Wrapper, etc.) support this feature also. Search for “Natural Logon” or “Natural Security” in the respective wrapper documentation.
  2. The SYS libraries SYSRPC, SYSLIB and SYSLIBS are not required anymore as steplib for the Natural IDL extractor if you are using a supported “Natural Version” and supported “EntireX Workbench” except if the Natural RPC Server runs under OS/400.
    Only the library SYSIDL must be allowed to be accessed by the user doing the extraction with the Natural IDL extractor.
    Regards Bernhard

Thanks to all for your responses. I have found in Designer where to make the appropriate setting. I have a question though about the impact to the already-deployed services. If I change this one and it actually makes a LOGON SRWEB to the library that new service is executed in, does the Natural RPC Server then log back into its original library WS-LIB, or will all services now need to perform a LOGON to their own respective libraries since they won’t be found from library SRWEB?

Yes, the Natural RPC Server will log back to the default library in the case you describe.

When I’m setting up Natural RPC Server for customers, I often recommend using LOGONRQ=YES, which requires all client applications perform a Natural Security logon. In your case, if you want to migrate to using the separate application libraries, you might set up a new server (with a new server name) with LOGONRQ=YES and make it available to new or modified services.