Natural Subpgm(as a web service) Calling another Web Service

, ,
1

Hi,

Scenario:
I have a sub program (ELVRWS03) that calls a web service (ELRPC001).

Case 1 (Works Fine):
A Natural Program calls subprogram ELVRWS03. EVLRWS03 then calls web service ELRPC001 and everything works fine.

Case 2 (NAT0082 is encountered):
I “exposed” ELVRWS03 as a web service. A consumer (.NET Application) calls ELVRWS03 and works fine until ELVRWS03 calls web service ELRPC001. The exact error message I have is:

Broker Error 1001 0016: Callee not found. Library: VRWEBSERVICE, Program: ELVRWS03 ELVRWS03 4910 NAT0082 Invalid command, or Subprogram ELRPC001 does not exist in library., NE=01,ELVRWS03491002O

Is there a way to make this approach work?

Thank you very much.

Regards,

Chris

2

Chris,
it appears that you did you set AUTORPC=ON for the Natural RPC server that exposes ELVRWS03 as a web service´.

3

Hi Wolfgang,

After checking I found that AUTORPC=ON was NOT included.

a) Original Settings: RPC=(SERVER=ON,RPCSIZE=1040,MAXBUFF=1024,…

Result: Broker Error 1001 0016: Callee not found. Library: VRWEBSERVICE, Program: ELVRWS03 ELVRWS03 4910 NAT0082 Invalid command, or Subprogram ELRPC001 does not exist in library., NE=01,ELVRWS03491002O

b) Added AUTORPC=ON
Result: Broker Error 1014 6974: Natural RPC Server returns: ELVRWS03 4910 NAT6974 Conversion error on Client, reason 7 ,000., NE=01,ELVRWS03491002O

Natural Help Details
NAT6974, Reason 7 = No space for working storage in RPC size. Increase RPC size on :1: side.

c) Increased RPCSIZE=9999
Result: Broker Error 1014 6971: Natural RPC Server returns: ELVRWS03 4910 NAT6971 Connection error on Client, reason 7 ,RPCXMLOUT /BKR144., NE=01,ELVRWS03491002O

Natural Help Details
NAT6971, Reason 7 = Node not active.
After the reason, the message displays the server/node in question.
With AUTORPC=ON this error may also occur instead of a local NAT0082
error on the client side.

Just to make sure that the server was working fine and isolate “Node not active” error, I tested calling another natural subprogram that I ‘exposed’ as a web service(ELVRWS02). ELVRWS02 is very basic/simple and does not call another web service like ELVRWS03. ELVRWS02 completed successfully.

Unfortunately adding AUTORPC=ON did not resolve the issue.

Hope the above information helps.

Thanks,

Chris

4

Chris,
our Natural RPC server tries to access BKR144 via Adabas communication.
Does your Natural RPC server and BKR144 run on the same mainframe?
Regards, Wolfgang

5

Hi Wolfgang,

I’m still gathering the required information to reply to your query and will post it here as soon as possible.

In the meantime I would like to clarify the components involved in my scenario:

a) ELVRWS03 - is a Natural Subprogram exposed as a Web Service.
b) ELRPC001 - refers to a third party Web Service written in JAVA. It is consumed via a CALLNAT statement in ELVRWS03.

Process Flow:
Step 1) A .NET Application consumes web service ELVRSWS03.

Step 2) ELVRSWS03 will process the data supplied by the .NET Application. As part of the ELVRWS03 process, it will consume ELRPC001 (this is the part that fails).

In summary:
.NET Application (Windows Forms) -----> ELVRSWS03/Natural Subprogram (as Web Service) -----> ELRPC001/Java Application (Web Service)

Can I assume that your current RPC Server and Mainframe setup allow you to achieve this process/approach successfully?

Thanks,

Chris

6

Hi Chris,
a Natural RPC server can consume a web service. In this case the Natural RPC server has also to be setup as a Natural RPC client.
Best regards,
Wolfgang

7

Hi Wolfgang,

You asked: Does your Natural RPC server and BKR144 run on the same mainframe?

Answer: Yes, BKR144 and the Natural RPC service RPCXMLOUT are both residing on the same mainframe

When you said “the Natural RPC server has also to be setup as a Natural RPC client”, do the changes need to be made in SYSRPC on the mainframe or on the XML Runtime server?

Thanks,

Chris

8

Problem is on the Natural RPC side, not the XML run time. You need to make sure that the Natural that is running the RPC server has the SYSRPC (NATCLTGS) module available and either is running with AUTORPC=ON or has a stub generated.

Whatever configuration you needed to make the CALLNAT to the web service work when called from the Natural program needs to also be available to the Natural RPC Server.

9

Hi all. I’m Chris’s system admin on the mainframe side of the equation.
Since I’m not sure Chris is being completely clear about what he is attempting to do I’ll share my understanding.

Chris has an application that currently resides and is accessed via the mainframe. The mainframe application makes a CALLNAT to a Natural subprogram (ELVRWS03) that in turn does a CALLNAT to a web service (ELRPC001). This works successfully for him.

He is now trying to allow another user to access the application. This user is not coming from a mainframe application but rather a PC client application. Therefore, Chris “exposed” the Natural subprogram ELVRWS03 to the PC Client as a web service using the Workbench.
The PC Client can execute the “exposed” web service ELVRWS03 correctly but then has problems when ELVRWS03 attempts to CALLNAT another web service (ELRPC001).

My first question (and probably not my last on this topic) - can a web service on the mainframe call another web service?

Douglas, Chris is using an already existing RPC service - this is not a new RPC service. So when you say “Whatever configuration you needed to make the CALLNAT to the web service work when called from the Natural program needs to also be available to the Natural RPC Server.” how would this be accomplished? I’m under the impression that the configuration is already there and working for him.

I must admit - I’m relatively new to the whole web service/RPC thing and have only been doing systems admin work for SAG products for the last 2 years or so. I have a lot to learn and am still trying understand all the nuances of the products. Please bear with me if I end up asking a lot of questions that seem to be overly basic.

Deb

10

Hi all,
I’m not sure to understand all the details given so far, but in a similar case, where node was not reachable when TCP/IP communication was involved, I had to append the portname when defining the broker name i.e. :18024.
Just an idea …
Aldo

11

Hi Chris,
the comment of Aldo is correct. Depending on the used EntireX Broker stub the default communications method is either NET or TCP.
If your Broker BKR144 is not found, there is a good chance that the EntireX Broker stub tries to use TCP/IP instead of NET.
Please try one of the following names for your EntireX Broker:

  • BKR144::NET
    (to enforce NET communication to DBID 144)
  • :
    (to enforce TCP/IP communication to port on host )
    is the name of the host on which the Broker is running. I would also recommend to append the domain name.
    Best regards,
    Wolfgang
12

Chris,
regarding the modifications to your existing Natural RPC server to act as a Natural RPC client:

  1. add the RPC profile parameters that are already used by your existing Natural RPC client
    (DFS, AUTORPC)
  2. correct the EntireX Broker ID in DFS as already recommended
  3. double the value for RPCSIZE
    Best regards
    Wolfgang
13

Hi Wolfgang, Aldo and Douglas,

Thanks for the suggestions. I tried the following changes:

a) Include subparameter AUTORPC=ON
b) Double the RPCSIZE to 2080
c) Set subparameter SRVNODE=‘BKR144:18026:TCP’

I’m still getting the error:

Broker Error 1014 6971: Natural RPC Server returns: ELVRWS03 4910 NAT6971 Connection error on Client, reason 7 ,RPCXMLOUT /BKR144., NE=01,ELVRWS03491002O

Your comments and suggestions really help me to try to make this work. However someone made a comment that this is NOT POSSIBLE. This CANNOT be achieved. As for the changes in subparameter values his comments were:

I hope I’m not chasing a ghost. What do you think? Is this scenario really possible?

.NET Application (Windows Forms) ---(consumes)--> ELVRSWS03/Natural Subprogram (as Web Service) ---(consumes)--> ELRPC001/Java Application (Web Service)

Is this one of those conceptually possible but will not work technically? Perhaps our environment does not support this unlike yours?

Thanks,

Chris

14

It absolutely can and does work. I have a customer that has been doing this for many years already.

The NAT6971 reason 7 indicates that it can’t reach that Broker node “BKR144”. The error message doesn’t show the port number, which suggests it is not picking up the override parameters you are trying to put in as part of the DFS settings.

Are you using SYSRPC/NATCLTGS, DFS parameters or the USR2007N API to set your target Broker and server? I’d suggest using USR2007N, at least to start, as it gives you the closest control over where the CALLNAT will go to.

RPCSIZE applies to both the client and the server.

Deb: I don’t know exactly how Chris is calling the web service from his Natural client compared to how the Natural RPC Server does it. Are all of the NATPARMs the same in each case? Is the Natural RPC Server logged on to the same library as Chris was using when he does the Natural client call? Or does the RPC Server subprogram set the library before attempting its call? If not, the NATCLTGS and steplibs may be different. Using USR2007N in both cases ensures that the same configuration is being used.

15

Hi Douglas,

Inside ELVRWS03 I use USR2007N just before calling Web Service ELRPC001.

 CALLNAT 'USR2007N' 'P' #BROKER-ID #SERVER #LOGON #PROTOC  
 CALLNAT 'ELRPC001' WSREQUEST(AD=O) WSRESULT(AD=A)

Where:
ELVRWS03 = The Natural Subprogram I exposed as a web service so that a .Net Application can consume it.

ELRPC001 = refers to a Web service written in Java and is outside of the mainframe.

I’ll wait for Deb’s answers to your questions. Hopefully it may lead me/us to something.

Thanks a lot!

Regards,

Chris

16

so what are you passing in as #BROKER-ID to USR2007N? According to the error message, you are passing “BKR144”, but, according to the other comments, it needs to be a TCP/IP address and port number.

If you go to a TSO session READY prompt and enter “ping BKR144”, does it respond with an IP address and response time? - something like:


 CS V1R10: Pinging host DDDD.co.com (10.20.91.20)        
 Ping #1 response took 0.001 seconds.

or does it respond with “unknown Host ‘BKR144’”? If the host name is unknown, try using “127.0.0.1:18026” as the Broker ID.

You don’t have to use TCP/IP to talk to the Broker from the Natural RPC Server. If the Broker’s DBID is 144, then “BKR144” (or “BKR144::NET”) should use SVC to communicate with it.

17

Hi Douglas,

a) Data being passed to USR2007N:

#BROKER-ID: BKR144
#SERVER: RPCXMLOUT
#LOGON:           
#PROTOC: B

b) The response I got from “ping BKR144” in TSO:

CS V1R10: Pinging host BKR144.xxxxx.xxxx.xxx (yyy.yy.yy.y)
Ping #1 response took 0.000 seconds.

I suppose the result in b) is a good sign?

Thanks,

Chris

18

You probably need to pass
#BROKER-ID: BKR144:18026:TCP

19

Hi Rolf,

I changed the Broker ID before calling USR2007N as you have suggested.

Test #1: Natural Program calling the Natural Subprogram
Result:

NAT0954 Abnormal termination AEY9 during program execution.

Test #2: .Net Application calling the Natural Subprogram as a web service
Result: SUCCESS! IT WORKED! FINALLY! AWESOME! WOW!

Note: I almost gave up after Test #1 but for some reason I still tried going for Test #2.

Summary: In order to achieve this
a) AUTORPC=ON is required in the RPC Server.
Otherwise this error will come out:
Broker Error 1001 0016: Callee not found. Library: VRWEBSERVICE, Program: ELVRWS03 ELVRWS03 4910 NAT0082 Invalid command, or Subprogram ELRPC001 does not exist in library., NE=01,ELVRWS03491002O

b) RPCSIZE must be increased in the RPC Server.
Otherwise this error will come out (even with AUTORPC=ON):
Broker Error 1014 6971: Natural RPC Server returns: ELVRWS03 4910 NAT6971 Connection error on Client, reason 7 ,RPCXMLOUT /BKR144., NE=01,ELVRWS03491002O

c) Broker ID must be absolute when calling USR2007N, i.e. include Port and Protocol.
Otherwise this error will come out:
Broker Error 1014 6971: Natural RPC Server returns: ELVRWS03 4910 NAT6971 Connection error on Client, reason 7 ,RPCXMLOUT /BKR144., NE=01,ELVRWS03491002O

d) Refer to result of Test #1 on error.
Workaround: If caller is Natural/Mainframe use BKR144 without Port No and TCP.

A Big Thanks To ( In order of appearance :smiley: )
Wolfgang Weil
Douglas Kelly
Aldo Teusch
Rolf Bahlke

I apologize to Wolfgang, Douglas and Aldo if this is what you’ve been trying to tell me but I was just too “slow” to get it.

Thank You Gentlemen! You’re the Best!

Regards,

Chris

20

You are using a different Broker stub between the online (CICS) and batch (RPC Server). Your CICS stub doesn’t support TCP/IP; batch does. Batch can support SVC if the right stub is used (which would allow “BKR144” as a Broker ID). Stubs vary a bit by EntireX version, so check your documentation.

With EntireX v8.1 you can do TCP/IP from batch or online. (below 8.1 you have to install the Relay Manager…just upgrade!)