WSO2 Enterprise Integrator Unable to call deployed API - json

I am completely new to WSO2 and I am facing the problem described below.
After deploying the API (composite application *.car file) I am unable to invoke the services of the defined endpoints from WSO2 ESB.
The REST API I am trying to invoke is found deployed on a local tomcat installation, and is located at:
http://localhost:8080/CustomerInfoRestService/customers/
To retrieve a json customer object I would simply add the customer id, like so:
http://localhost:8080/CustomerInfoRestService/customers/2
All the services operations (Get, POST, PUT, DELETE) are tested and invoked successfully. For testing I used the tool 'PostMan'.
I created an ESB project using the WSO2 Integration Studio.
First I defined an endpoint with a URI Template of:
http://localhost:8080/CustomerInfoRestService/customers/{uri.var.custId}
Then I defined a REST API. The properties of the API Resource are as follows:
URL-Style: URI_Template
URI-Template: /customers/{custId}
Methods: GET
In the In-Sequence I added a log mediator, having:
Log Category: INFO
Log Level: CUSTOM
and I defined its message as:
Property Name: message
Property value type: LITERAL
Property Value: Welcome to Customer Service
Directly next to the log mediator is a 'Send' mediator, and I included the defined endpoint above.
Then I deploy the composite application as: right-click -> Export Composite Application Project.
I include both the API and and the endpoint in the generated *.car file.
Now to invoke an API request, I call the service using 'curl':
curl -v http://localhost:8280/CustomerInfoRestService/customers/2
and I get the response:
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8280 (#0)
> GET /CustomerInfoRestService/customers/2 HTTP/1.1
> Host: localhost:8280
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Thu, 13 Jun 2019 10:09:06 GMT
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
It seems not to be found (404 error)
I followed the WSO2 documentation, specifically the integration tutorial "Sending a Simple Message to a Service" to create this project, for reference it is found at:https://docs.wso2.com/display/EI650/Sending+a+Simple+Message+to+a+Service
Any help is greatly appreciated.
Thanks in advance,
Kind Regards,

This kind of response comes when the API is not deployed or active in the ESB. Did you deploy the car file you created? You did not mention that in your steps. Please make sure that you are able to see the API in the management console (Home -> Service Bus -> API).

Related

How to call Workflows via API Gateway Config?

I've changed my approach and turned to what worked earlier. I configured an API gateway to call the Google Cloud Functions and it called them with the appropriate permissions when I passed in an api key. I think it's erroring when trying to call the workflow because I didn't specify a resource. Not sure exactly though... It looks like the API key is working, but the OAuth is failing. My OAuth is configured with a fresh connection since I've made the workflow. It's authenticated on my end, I clicked my account in google and everything. I'm 99.99% sure the OAuth is configured correctly. When I called the GCP function with the API Gateway, I didn't have to use OAuth.
Is OAuth a requirement for the Workflows API? Are there any work arounds?
How to specify the params for the Workflow in the API Gateway config?
Named Credential:
Label GoogleCloudFunction
Name GoogleCloudFunction
URL https://workflowexecutions.googleapis.com
Hide Section - AuthenticationAuthentication
Certificate
Identity Type Named Principal
Authentication Protocol OAuth 2.0
Authentication Provider GoogleCloudAuth
Scope https://www.googleapis.com/auth/cloud-platform
Authentication Status Authenticated
Log from API Gateway:
httpRequest: {
latency: "0.039s"
protocol: "http"
requestMethod: "POST"
requestSize: "1269"
requestUrl: "/create-site-tracker-site?key=HIDDEN"
responseSize: "743"
status: 401
}
insertId: "48330ec2-7114-4270-b465-68ae6308bdc34850908905639612439#a1"
jsonPayload: {
api_key: "HIDDEN"
api_key_state: "VERIFIED"
api_version: "1.0.0"
http_status_code: 401
location: "us-central1"
log_message: "1.create_site_tracker_site_0s5865srg8pbr_apigateway_quick_hangout_329722_cloud_goog.CreateSiteFunction is called"
response_code_detail: "via_upstream"
}
API Config
# openapi2-functions.yaml
swagger: '2.0'
info:
title: create-site-tracker-site with auth
description: Create Site in Site Tracker using JSForce
version: 1.0.0
schemes:
- https
produces:
- application/json
paths:
/create-site-tracker-site:
post:
summary: Create Site
operationId: createSiteFunction
x-google-backend:
address: https://workflowexecutions.googleapis.com/v1/projects/us-central1-quick-hangout-329722/locations/us-central1/workflows/create-site-and-project/executions
security:
- api_key: []
responses:
'200':
description: A successful response
schema:
type: string
securityDefinitions:
# This section configures basic authentication with an API key.
api_key:
type: "apiKey"
name: "key"
in: "query"
Your HTTP request appears to include no "Authorization" header. Without this it is unlikely that you're call will succeed unless your Cloud Functions permit unauthenticated calls.
It's difficult to understand what you're doing because e.g. "works when I test it manually" is imprecise and provides little information about what you did. I assume (!?) you're using gcloud functions call which authenticates for you.
Please add more detail to your question include the commands that you tried and those that succeed and fail and include error messages.
The majority of Google's services are exposed as REST APIs and so you can invoke almost everything using simple HTTP commands.
Current work around is calling the workflow from a google cloud function, and then calling the function via API Gateway and passing a key. Gross but it works

Postgraphile "Only `POST` requests are allowed." error

I have Postgres running locally. I can access the database locally with psql postgres:///reviewapp and with \dt I can see a few tables.
If I run npx postgraphile -c "postgres:///reviewapp" I dont get any errors in the terminal:
PostGraphile v4.12.4 server listening on port 5000 🚀
‣ GraphQL API: http://localhost:5000/graphql
‣ GraphiQL GUI/IDE: http://localhost:5000/graphiql (RECOMMENDATION: add '--enhance-graphiql')
‣ Postgres connection: postgres:///reviewapp
‣ Postgres schema(s): public
‣ Documentation: https://graphile.org/postgraphile/introduction/
‣ Node.js version: v14.15.5 on darwin x64
‣ Join Mark in supporting PostGraphile development: https://graphile.org/sponsor/
* * *
However when I go to http://localhost:5000/graphql I have an error on the screen:
{"errors":[{"message":"Only POST requests are allowed."}]}
You're visiting the /graphql endpoint which speaks GraphQL (over POST requests), but you're sending it a web request (over GET). Instead, use the /graphiql end point to view the GraphiQL GraphQL IDE - this endpoint speaks web, and will give you a nice interface for communicating with the /graphql endpoint. See this output from the PostGraphile command:
‣ GraphQL API: http://localhost:5000/graphql
‣ GraphiQL GUI/IDE: http://localhost:5000/graphiql (RECOMMENDATION: add '--enhance-graphiql')
I recommend you add the --enhance-graphiql option to the PostGraphile CLI to get an even more powerful IDE in the browser.
It is because when you type in your address into the address bar of your browser, a GET request is being sent, while your Postgraphile instance only accepts POST requests. So this is the problem. You either avoid sending GET requests, or try and ensure that Postraphile accepts GET requests as well.
A very simple solution would be to create a very simple and small website that will act as a proxy and upon load, it would send a POST request to http://localhost:5000/graphql
There is a GitHub ticket where a middleware is suggested, read this for further information: https://github.com/graphile/postgraphile/issues/442

how is the traffic to the openshift_cluster_hostname is redirected to the openshift web console

Question 1 :
1.1. who is sitting behind the "openshift_master_cluster_public_hostname" hostname ? is it the web console ( web console service ? or web service deployment ) or something else ?
1.2. when doing oc get service -n openshift-web-console i can see that the web console is runnung in 443 , isn't it supposed to work on port 8443 , same thing for api server , shouldn't be working on port 8443 ?
1.3. can you explain to me the flow of a request to https://openshift_master_cluster_public_hostname:8443 ?
1.4. in the documentation is
Question 2:
why i get different response for curl and wget ?
when i : curl https://openshift_master_cluster_public_hostname:8443 , i get :
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/",
"/apis/admissionregistration.k8s.io",
"/apis/admissionregistration.k8s.io/v1beta1",
"/apis/apiextensions.k8s.io",
"/apis/apiextensions.k8s.io/v1beta1",
...
"/swagger.json",
"/swaggerapi",
"/version",
"/version/openshift"
]
}
when i : wget https://openshift_master_cluster_public_hostname:8443 i get an index.html page.
Is the web console answering this request or the
Question 3 :
how can i do to expose the web console on port 443 rather then the 8443 , i found several solution :
using variables "openshift_master_console_port,openshift_master_api_port" but found out that these ports are ‘internal’ ports and not designed to be the public ports. So changing this ports could crash your OpenShift setup
using an external service ( described here )
I'm kind of trying to setup port forwarding on an external haporxy , is it doable ?
Answer to Q1:
1.1. Cite from the documentation Configuring Your Inventory File
This variable overrides the public host name for the cluster,
which defaults to the host name of the master. If you use an
external load balancer, specify the address of the external load balancer.
For example:
> openshift_master_cluster_public_hostname=openshift-ansible.public.example.com
This means that this Variable is the Public facing interface to the OpenShift Web-Console.
1.2 A Service is a virtual Object which connects the Service Name to the pods and is used to connect the Route Object with the Service Object. This is explained in the documentation Services. You can use almost every port for a Service because it's virtual and nothing will bind on this Port.
1.3. The answer depend on your setup. I explain it in a ha-setup with a TCP loadbalancer in front of the masters.
/> Master API 1
client -> loadbalancer -> Master API 2
\> Master API 3
The Client make a request to https://openshift_master_cluster_public_hostname:8443 the loadbalancer forwards the Client to the Master API 1 or 2 or 3 and the Client get the answer from the requested Master API Server.
api server redirect to console if request come from a browser ( https://github.com/openshift/origin/blob/release-3.11/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/patch_handlerchain.go#L60-L61 )
Answer to Q2:
curl and wget behaves different because they are different tools but the https request is the same.
curl behavior with wget
wget --output-document=- https://openshift_master_cluster_public_hostname:8443
wget behavior with curl
curl -o index.html https://openshift_master_cluster_public_hostname:8443
Why - is described in Usage of dash (-) in place of a filename
Answer to Q3:
You can use the OpenShift Router which you use for the apps to make the Web-Console available on 443. It's a little bit outdated but the concept is the same for the current 3.x versions Make OpenShift console available on port 443 (https) [UPDATE]

UltraESB when run from netbeans IDE gives "service not found" error in ultraesb soa toolbox but works fine when run from cmd

The following is default proxy service in ultraesb file "ultra-unit.xml"
<u:proxy id="echo-proxy">
<u:transport id="http-8280"/>
<u:target>
<u:inSequence>
<u:class name="sample.SimpleJavaMediation1"/>
</u:inSequence>
<u:inDestination>
<u:address>http://localhost:9000/service/EchoService</u:address>
</u:inDestination>
<u:outSequence>
<u:java><![CDATA[
System.out.println("Reply payload : " + mediation.readPayloadAsString(msg));
]]></u:java>
</u:outSequence>
<u:outDestination>
<u:address type="response"/>
</u:outDestination>
</u:target>
</u:proxy>
I run ultraesb from Netbeans IDE and run toolbox.bat from command line (as there is no other way to run toolbox). When i send message to "http://localhost:8280/service/echo-proxy" using Ultraesb toolbox, it gives me following error
HTTP/1.1 404 Not Found
Date: Mon, 13 Jun 2016 07:34:40 GMT
Server: UltraESB/2.3.0 (GA)
Content-Length: 17
Content-Type: text/plain; charset=ISO-8859-1
Connection: close
Service not found
BUT when i run ultraesb.bat and toolbox.bat from commandline cmd....the service is perfectly accessed in toolbox and no error appears....
I really cant understand whats the issue...
Toolbox doesnt have log file whereas ultraesb log file exists which doesnt have any exception....no exception appears on Netbeans IDE console also. Please Help.
By looking at your description it seems like the proxy service has not been deployed over the 8280 transport listener, as there doesn't seem to be any error logs on the UltraESB log. This could happen if the deployment unit is not deployed. NetBeans IDE configuration on the standalone distribution of UltraESB ships with 2 run profiles of UltraESB one for the default server, another for the samples. If you are running the sample run profile it doesn't by default deploy the deployment units.
You got to either run the default server run profile or enable the deployment units in the environment bean of the ultra-root.xml. For more information on the NetBeans IDE setup please refer to the documentation

502 (BAD GATEWAY) and 504 (GATEWAY TIMEOUT) in Wirecloud

Time ago we set up a PEP proxy to secure the API our widgets are using. All have being working correctly until today, that we are receiving a 502 Bad Gateway error code for every call going through the proxy.
We have checked the requests are reaching our server and it is responsing correctly to them. The parameters added by the proxy (x-nick-name, x-display-name...) are defined correctly too.
We have also checked the requests outside wirecloud and all go well: we get the token properly and use it in the subsequent calls without problem.
We do not know where this error comes from, any ideas?
EDIT 06/11/2015
After Alvaro's new setting we are receiving the following error in the response body:
{
"description": "Connection Error",
"details": "('Connection aborted.', error(104, 'Connection reset by peer'))"
}
EDIT 09/11/15
Today, the code received in the request's response is different: 504 GATEWAY TIMEOUT
{
"description": "Connection Error",
"details": "('Connection aborted.', error(104, 'Connection reset by peer'))"
}
EDIT 16/11/15
Answering to Mr. Alonso's question:
1.- If we request directly to the server, the response is correctly displayed in the application.
2.- Here you can see the logs from the PEP Proxy with the new line added. As you can see the request is redirected correctly but the info is not displayed in the app.
Seems that the problem is in the PEP proxy side.
I've checked using other tools like curl (I obtained the connection details from the server log). Making the same request using curl gives the same result than using WireCloud: connection reset by peer. Also, if I make the request without the X-Auth-Token header, your service responds with an 401 error code. This is important, because it means that there is not a communication problem between the Mashup portal and your server. I don't know why, but the PEP proxy seems to be crashing when making the authenticated request from the Mashup portal (the same command works executing it from my machine).
I suggest you to restart the PEP proxy. If the problem persist, please attach any available info about the crash from the PEP proxy logs.
You can check three things to give us more information:
Try to remove the PEP and send the request directly to your service.
Introduce a new log in PEP to print the headers of the response: line 41 of lib/HTTPClient.js, log.debug("Headers: ", headers);
Try to send a request to the root path (directly to the tomacat or apache)
If not perhaps we can talk in private to check more information