Based on good suggestions provided by support and by members of this community, I am successfully renaming the IDL library and object name to provide more manageable naming conventions and avoiding the duplicate names generated where every IDL object is now called PROCESS.

However, when I generate the Natural RPC client object (which I have heard called a stub), it still creates it with the name PROCESS. This isn’t something we can handle since from Natural we need to be able to call all these different services and they cannot share a common stub interface object.

Is there somewhere I need to change something so the generated object uses the IDL object name instead of PROCESS? What I am trying now is to rename them after generation to the desired name I gave the IDL object, and early indications are this will work ok though I am running into other issues seemingly unrelated. But I would like it to just generate it with desired names instead of manually renaming them if possible.

Thanks,

Brian, did you specify PROCESS as the alias name of the program? This would explain that the Natural RPC client object is generated with this name.

Hi Rolf,

The system created process as the alias. I thought I needed to rename the IDL object name, but you’re saying I needed to change the alias name instead? Or do I need to change both to be like this to do what I need it to do?

library ‘DBSYSTEM’:‘CustomSOACreateSalesOrderListGvReqABCSImplv1_client_ep’ is
program ‘WS0200N1’:‘WS0200N1’ is
define data parameter

Will that still work?

Thanks,

in previous reply Brian, I suggested not to use alias and hence to uncheck create Unique names.
This was intentionally for you to have one name subject to rename as you wish, shmuel

Shmuel,

I haven’t seen that option, but I will look for it next time. I know there are options to flip the left/right side names though.

This is v8.2.2 with latest fixes.

hi brian, my point is very geared to renaming the program name so that you control the names for Natural artifacts.
this is based on real life customer.
we must not get into name:alias nor alias:name
just program name; my customer is rnaming the name to 6 characters long using Edit XML mapping.
shmuel

If there is an alias name the Natural Wrapper uses the alias name for the name of the generated Natural interface object. If there is no alias name it will use the program name.

You have a couple of possibilities: if you use alias names then change the alias name. If you don’t use alias names then change the program name.

Remember that “change name” has always to be done in the EntireX XML Mapping Editor which will change the IDL file once you save the changes. So IDL and XMM file are in sync.

Since the origin of your problem is that you have different web services with the same name the obvious 1:1 mapping to Natural would be to use different Natural libraries for each web service. Then you don’t have an issue that the programs are named “PROCESS” because they are in different libraries. But that might complicate your Natural client application logic …

Thanks Rolf and Shmuel!

I sought clarification from support on your suggestions and was able to demonstrate what you meant. I am now going to go forward with the ‘no alias’ option by unchecking the box that creates either the right or left side alias names (depending on which radio button I click). I think I was resistant mostly because it seemed to be a featured geared for if we are using a Natural RPC client. It’s ironic that for use of Natural RPC clients it’s best to avoid generating aliases designed for use with Natural RPC clients.

Anyway, by following this procedure, I was able to rename them in the XMM outline view, generate the new IDL backwards with the new names and generate client objects matching the IDL object name.

One thing I seem to have to give on is that I need to follow the naming convention where the last character is the object type. We use the 7th character for this in our shop’s standards, but since the PDA is generated also it makes no sense for it to be called WS0200NA to go with WS0200N1 (and WS0200NP also makes no sense). I will have to call this WS02000N so it generates also WS02000A and WS02000P.

Thanks for your help!

It’s a bit difficult to disagree on this

The alias handling evolved in various directions over the last 10+ years and today we are in a situation which is not satisfactory. We have plans to streamline this; maybe the next EntireX version shows an improvement in this area.