E9.2 API tester works but we get error 500 'message': 'Endpoint not defined with real system

[Elcin]

Hello all,

I am new to using JDEO, and I am currently stuck at calling JDEO from outside via REST API connection.

I made a simple orchestration, it is just a data request which returns a json file. and I would like this data to be called/used from outside systems.
My understanding is this kind of stand alone JDEO is basically a REST API and when used with correct link and correct JDE user authorization external system should be able to get the json output from AIS server,
I tested access to this JDEO from outside via TALENT API tester and it was successful. However when we try to call it from an actual external system, we are getting below error

{'message': 'Endpoint not defined: JDEOname. Add the orchestration, or make sure it is shared to this user.', 'exception': 'Exception', 'timeStamp': '2023-01-31T15:05:39.004+0100', 'status': 'ERROR'}

I made sure the orchestration is shared/have security rights with the JDE user which is used as authorization for connection, (JDEO is created by my user but aprroved/shared/security added with the connection JDE user, of course all components) I even added it to a new OMW check out/check with the JDE user, also added the JDE user as originator to this OMW, and when I run it manually from JDEO studio with the connection JDE user it works with no issues.

If relevant, we are on tool release 9.2.5.4 , everything is happening in our DV envionment (this JDEO itself is only in DV and connection link is made to DV)

the API link we are using is like below,

https://our internal server with port/jderest/v3/orchestrator/JDEO name

 

[DaveWagoner]

First thanks for the great write up!

Here's the big issue I see: you try to call the API using TALENT API tester at https://our internal server with port/jderest/v3/orchestrator/JDEO name from outside of your internal network, and you are simulating an external system. This works fine.

Next you try to call https://our internal server with port/jderest/v3/orchestrator/JDEO name from the actual external system from outside of your internal network and see that error message.

Is it possible to compare the CURL command in each tool? I suspect there's a difference in calls that is causing this. The external system may be tacking on extra chars to the Orch name path for instance, or authing a different way.

Here's curl I got from using Postman to access one of our orchestrations. It makes comparing calls between systems a simple text compare to see what the differences are. Hopefully your external system lets you see the entire contents of the call to your orch.

curl --location --request POST 'http://ORCHSRVR:PORT/jderest/v3/orchestrator/ORCH_ORCHNAME' \
--header 'Accept: xml' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic GIBBERISH' \
--data-raw '{...

 

[DaveWagoner]

First thanks for the great write up!

Here's the big issue I see: you try to call the API using TALENT API tester at https://our internal server with port/jderest/v3/orchestrator/JDEO name from outside of your internal network, and you are simulating an external system. This works fine.

Next you try to call https://our internal server with port/jderest/v3/orchestrator/JDEO name from the actual external system from outside of your internal network and see that error message.

Is it possible to compare the CURL command in each tool? I suspect there's a difference in calls that is causing this. The external system may be tacking on extra chars to the Orch name path for instance, or authing a different way.

Here's curl I got from using Postman to access one of our orchestrations. It makes comparing calls between systems a simple text compare to see what the differences are. Hopefully your external system lets you see the entire contents of the call to your orch.

curl --location --request POST 'http://ORCHSRVR:PORT/jderest/v3/orchestrator/ORCH_ORCHNAME' \
--header 'Accept: xml' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic GIBBERISH' \
--data-raw '{...

Check also POST vs GET. Some tools default to GET and we forget to change over to POST, or vice versa

 

[Elcin]

Thanks for your input! Before checking the point you mentioned, actually your reply made me realize a rookie mistake I made, because when I tested with TALENT API I still had my vpn on so technically it was not really testing it from outside.
so first I tried that and sure enough when I try TALENT API without vpn connection to our domain, I get no responce Is the certificate valid message, so even though the message we got from the actual external system is about endpoints, it maybe related to this then?
I will need to pass this info to my infra collegues since I do not know how to bypass this but I assume we will need to define an additional security point/authantication point for the external system.