ESB : works well running from Studio but not from the runtime

[Alpha549]

Hello everyone,

I'm playing with ESB, and I created a simple job using a tRestRequest and tRestResponse. It works perfectly executing from the Studio, and Postman (or directly in the browser). However, when I use trun locally (after stopping the job in the Studio), it doesn't work, I have no response. My bundle is Active (bundle:status id)...

In the browser I get the message :

localhost doesn't authorize connection

ERR_CONNECTION_REFUSED

I might not have done something which is necessary

Thank you for your light 🙂

[Alpha549]

I've renamed the job, and here it is :

 

 

Here is the tesb.log : https://pastecode.io/s/m08df6tu

This should be correct now, sorry

[Anonymous · Accepted solution]

OK, I believe I know what is going wrong for you here. This is down to a configuration of the TOS ESB settings. Open Preferences and go to the Maven branch. You should see this....

The 2 tick boxes that I have circle, need to be unticked. Then click "Apply and Close".

After that, recompile your service, remove the old one from your deploy folder and add the new one. You should then see it appear on the http://localhost:8040/services screen.

EDIT: On second thoughts, only untick the "Offline" tick box. That should solve this for you. Leave the other one ticked. Try with that first. If it doesn't work, then untick the other option.

[Alpha549]

IT WORKS ! Thanks you @Richard Hall​ 

Ok Maven was configured on Offline. Indeed, the generated jar was very small, about 2ko. Now it's online, the generated jar is about 4MO ! 🙂

 

🙂

I have another question @Richard Hall​ 

I want to have very simple jobs. It's also to be able to update api methods.

I have one job which return hello :

 

 

And another one to say bye :

 

 

As I don't specify any port in REST Endpoint, I saw that my bye bundle status is Failure

 

As they are different jobs, the port should be different isn't ? So should I specify the port manually in REST Endpoint ?

[Anonymous]

I suspect that this is because they both share the same REST Endpoint. If you stop the "api_hello" service and restart the "api_bye" service, you will see that it will work.

To get around this all you need to do is either give them different endpoints OR (a better solution in this case), have an output for "hello" and an output from "bye" in the same tRESTRequest component in the same job. You then have 2 paths coming from the tRESTRequest and you can just link the paths you are showing in your 2 jobs into the 1 job.

[Alpha549]

"I suspect that this is because they both share the same REST Endpoint. If you stop the "api_hello" service and restart the "api_bye" service, you will see that it will work."

Yes it's what I think. There is the same port 8040 and the same endpoint /api/ in the beginning.

So I did like this :

 

And

 

The services page I get :

 

It's perfectly what I want.

Now the two job are not interdependent. Somebody can work on a job, so an endpoint, and another one can work on another endpoint. The two endpoints can be updated without having any effect or another one.

I could put the two flows in the same job, but the job would become gigantic with more endpoints, so here it's simple, what I want 🙂

I have another question haha :

On the deployment server (Linux), there is no visual interface. The connection is via SSH. So I can't open any browser on localhost:8040/services

I had the idea of using curl "localhost:8040/services"

This works and I have a return like this :

 

Do you know if there is a prettier solution to get services URL or if I can use this one ?

[Anonymous]

I'm assuming your Linux server is on a network that you are on or have access to? If so, all you need to do is replace "localhost" with the server's IP address. You can look at it from any device with a visual interface.

[Alpha549]

Ok, yeah, simply like that, as the <IP address>:8040/services/endpoint doesn't change.

All my questions are answered now @Richard Hall​ 

Thank you very much for your help and patience ! 🙂