I tried to do the tutorials suggested on the MuleSoft's website.
I first started with this example:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.6.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd">
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8084" doc:name="HTTP Listener Configuration"/>
<flow name="basic_tutorialFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
<expression-filter expression="#[payload != '/favicon.ico']" doc:name="Expression"/>
<logger level="INFO" doc:name="Logger" message="Current payload is #[payload]"/>
<set-payload doc:name="Set Payload" value="#['Hello, ' + message.inboundProperties.'http.request.path' + '. Today is ' + server.dateTime.format('dd/MM/yy') + '.' ]"/>
</flow>
</mule>
Which can be found here http://www.mulesoft.org/documentation/display/current/Basic+Studio+Tutorial
I made it using the drag and drop feature and after that I copied the code on the website just to be sure it wasn't my mistake.
When I enter the URL with no payload it works well. I get this response
Hello, /. Today is 23/01/15.
But when I add a payload like in the tutorial it doesn't work :
Resource not found.
I have tried other examples as well, as long as I don't enter a payload it works. Here is what the console tells me :
INFO 2015-01-23 10:33:55,614 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.api.processor.LoggerMessageProcessor: Current payload is {NullPayload}
INFO 2015-01-23 10:34:32,794 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: (GET)/asd
INFO 2015-01-23 10:34:32,796 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: Available listeners are: [(*)/]
INFO 2015-01-23 10:34:36,205 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: (GET)/world
INFO 2015-01-23 10:34:36,205 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: Available listeners are: [(*)/]
So basically the problem is :
INFO 2015-01-23 10:34:36,205 [[basic_tutorial].HTTP_Listener_Configuration.worker.01] org.mule.module.http.internal.listener.HttpListenerRegistry: No listener found for request: (GET)/world
So with 3.6, the HTTP connector has changed drastically. Here are some changes:
Previously, the HTTP connector would place the contents of the path inside your payload. Moreover, now you need to invoke paths as is. What I mean is that nowadays, if your endpoint is listening on http://localhost:8084/, that's where you need to send the request. Sending a request on http://localhost:8084/HelloWorld will NOT match.
Sending a GET request now will set your payload to NullPayload, which admittedly makes sense, since an HTTP GET does not have an HTTP body.
What I suggest is the following: have your endpoint listening on a path as follows:
<http:listener config-ref="HTTP_Listener_Configuration" path="/{name}" doc:name="HTTP"/>
Notice that I've added a placeholder variable called "name", you can change this to whatever you like. You can then access this placeholder as follows:
#[message.inboundProperties['http.uri.params']['name']]
You can use this expression to return some fancy string, as you're doing above:
<flow name="basic_tutorialFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/{name}" doc:name="HTTP"/>
<set-variable variableName="name" value="#[message.inboundProperties['http.uri.params']['name']]" />
<set-payload doc:name="Set Payload" value="#['Hello, ' + flowVars['name'] + '. Today is ' + server.dateTime.format('dd/MM/yy') + '.' ]"/>
</flow>
Cheers,
JS
As told before, the HTTP Connector is deeply changed from version 3.6 onward.
Now, the connector only listen to the specific path you explicitly define.
My issue was that I wasn't even able to get the WSDL by the obious http://localhost:8080/soap?wsdl.
So, the easiest solution I found to solve this issue was to allow the connector to accept all subpaths by ending the path with the wildcard '*'.
Change your project.xml as I show here:
<http:listener config-ref="HTTP_Listener_Configuration" path="/*" doc:name="HTTP"/>
and all subpaths will be processed.
Related
I am Getting below error while calling a Mulesoft system api from mulesoft process API via DLB in the cloudHub.
The frequency of closing the remote connection error is not fixed.
Sometimes this error comes after 2 minutes and sometimes after 5 minutes.
Though, with second retry it works but still I want to avoid this error as its being happening very frequently.
HTTP POST on resource 'https://internal-nonprod-dlb.lb.anypointdns.net:443/api/sys/aws/s3/databricks/object' failed: Remotely closed.
Mule Version : 4.4
HTTP connector version: 1.7.3
DLB Timeout : 7 minutes
Payload size : ~ 30 MB System
APIs Listener Idle timeout : 5 Minutes
request configuration in process api
<http:request method="POST" doc:name="POST GZIP / aws system api" doc:id="0b490747-5069-4546-9446-8b77130ae848" config-ref="Aws_Sys_API_HTTP_Request_configuration" path="${awsSysApi.databricksPath}" responseTimeout="600000">
<reconnect />
<http:headers><![CDATA[#[output application/java
---
{
"client_secret" : p('secure::awsSysApi.client_secret'),
"Content-Type" : "application/gzip",
"client_id" : p('secure::awsSysApi.client_id')
}]]]></http:headers>
<http:query-params><![CDATA[#[output application/java
---
{
"bucketName" : p('aws.bucket.datalakeRawDeBucket'),
"key" : vars.key
}]]]></http:query-params>
<http:response-validator>
<http:success-status-code-validator values="200..499" />
</http:response-validator>
</http:request>
HTTP requests global configuration in process API
<http:request-config name="Aws_Sys_API_HTTP_Request_configuration" doc:name="HTTP Request configuration" doc:id="5a7eb30f-9850-4de5-8cca-a7d77b0c10d4" basePath="${awsSysApi.basepath}">
<http:request-connection host="${awsSysApi.host}" port="${awsSysApi.port}" protocol="HTTPS" connectionIdleTimeout="${awsSysApi.idletTimeout}">
<reconnection>
<reconnect frequency="${retry.millisecondsBetweenRetries}" count="${retry.maxRetries}" />
</reconnection>
<tls:context>
<tls:trust-store insecure="true" />
<tls:key-store type="jks" path="${tls.keyStore.path}" keyPassword="${secure::tls.keyStore.keyPassword}" password="${secure::tls.keyStore.password}" />
</tls:context>
</http:request-connection>
</http:request-config>
system APIs listener configuration:
<http:listener-connection host="${http.host}" port="${http.private.port}" readTimeout="300000" connectionIdleTimeout="360000">
<reconnection>
<reconnect frequency="30000" count="2" />
</reconnection>
</http:listener-connection> ```
Please let me know if i have missed any information.
Probably you system API is failing to process big payloads. It could be also related to concurrency, or both. Maybe insufficient resources.
You should try to reproduce locally with a similar memory configuration with different payloads to understand the issue.
The HTTP configurations alone are unlikely to be related to the issue. FYI the Connection idle timeout is not related to connection timeouts.
I wanted to know if we can configure multiple base path for a proxy endpoint in APIGEE. The target proxy remains same for both basepaths.
Example: I want to ensure /hello/world and /hello/universe route to same target endpoint and are treated in same way entirely
<HTTPProxyConnection>
<BasePath>world</BasePath>
<BasePath>universe</BasePath>
<VirtualHost>hello</VirtualHost>
</HTTPProxyConnection>
How to achieve the same?
The <VirtualHost> field should refer to an Apigee vhost, which is a Fully Qualified Domain Name ('FQDN'). That's a hostname like demo.api.company.com. E.g., everything before the first /.
Your proxy basepath is then /hello, like this:
<BasePath>hello</BasePath>
And then the rest of your API proxy definition uses flows and path-matching conditions to handle the different methods you want to operate at /hello/world vs /hello/universe
<Flow name="world_GET">
<Description>World GET</Description>
<Request>
<Step>
<Name>World01</Name>
</Step>
<Step>
<Name>World02</Name>
</Step>
</Request>
<Response/>
<Condition>((proxy.pathsuffix MatchesPath "/world") and (request.verb = "GET"))</Condition>
</Flow>
<Flow name="universe_GET">
<Description>Uni GET</Description>
<Request>
<Step>
<Name>Uni01</Name>
</Step>
<Step>
<Name>Uni02</Name>
</Step>
</Request>
<Response/>
<Condition>((proxy.pathsuffix MatchesPath "/universe") and (request.verb = "GET"))</Condition>
</Flow>
See:
https://docs.apigee.com/api-platform/reference/api-proxy-configuration-reference#proxyendpoint-proxyendpointconfigurationelements
I have the following problem with WSO2 API Manager and I suspect that it could be a problem related to certificate of the final HTTPS endpoint that it was registered.
I try to explain my situation in details:
First thing: I changed this section of the repository/conf/axis2/axis2.xml file in order to contact the 443 port instead the default 8243 port to call the registered endpoint over HTTPS (at the moment I can't change the registered end point port and I can't install a reverse proxy, but I have to test if the system works as expected, basically I need to call the final endpoint on the 443 port and I have to obtain the JSON response).
The original section that I changed is:
<transportReceiver name="https" class="org.apache.synapse.transport.passthru.PassThroughHttpSSLListener">
<parameter name="port" locked="false">8243</parameter>
<parameter name="non-blocking" locked="false">true</parameter>
<!--parameter name="bind-address" locked="false">hostname or IP address</parameter-->
<!--parameter name="WSDLEPRPrefix" locked="false">https://apachehost:port/somepath</parameter-->
<parameter name="httpGetProcessor" locked="false">org.wso2.carbon.mediation.transport.handlers.PassThroughNHttpGetProcessor</parameter>
<parameter name="keystore" locked="false">
<KeyStore>
<Location>repository/resources/security/wso2carbon.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
<KeyPassword>wso2carbon</KeyPassword>
</KeyStore>
</parameter>
<parameter name="truststore" locked="false">
<TrustStore>
<Location>repository/resources/security/client-truststore.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
</TrustStore>
</parameter>
<!--<parameter name="SSLVerifyClient">require</parameter>
supports optional|require or defaults to none -->
</transportReceiver>
I changed it in this way:
<transportReceiver name="https" class="org.apache.synapse.transport.passthru.PassThroughHttpSSLListener">
<parameter name="port" locked="false">443</parameter>
<parameter name="non-blocking" locked="false">true</parameter>
<!--parameter name="bind-address" locked="false">hostname or IP address</parameter-->
<!--parameter name="WSDLEPRPrefix" locked="false">https://apachehost:port/somepath</parameter-->
<parameter name="httpGetProcessor" locked="false">org.wso2.carbon.mediation.transport.handlers.PassThroughNHttpGetProcessor</parameter>
<parameter name="keystore" locked="false">
<KeyStore>
<Location>repository/resources/security/wso2carbon.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
<KeyPassword>wso2carbon</KeyPassword>
</KeyStore>
</parameter>
<parameter name="truststore" locked="false">
<TrustStore>
<Location>repository/resources/security/client-truststore.jks</Location>
<Type>JKS</Type>
<Password>wso2carbon</Password>
</TrustStore>
</parameter>
<!--<parameter name="SSLVerifyClient">require</parameter>
supports optional|require or defaults to none -->
</transportReceiver>
Basically I only changed the 8243 default port with 443 standard HTTPS port used to expose the final endpoint.
Now, executing the API from the Store portal I obtain a cURL command that works on the expected 443 port:
curl -k -X POST "https://ENDPOINT_IP_ADDRESS:443/puntualitest/v1.0.0/puntuali" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer XXXXX-YYYY-ZZZZ-KKKK-WWWW" -d "{ \"header\": { \"msgUid\": \"a36bea3f-6dc6-49d7-9376-f31692930ba9\", \"timestamp\": 1567060509108, \"metadata\": { \"TRACKER_BIZID_REV_CODICE\": \"7175\", \"TRACKER_BIZID_REV_NUMERO\": \"545/2019\" }, \"codApplication\": null, \"codEnte\": null, \"invocationContext\": null, \"caller\": \"SRW\", \"user\": null, \"service\": \"crediti.invioPosizioneCreditoria\" }, \"body\": { \"#dto\": \"binary\", \"content\": \"PD94bWwgdmVyc2..............................+\" }}"
This seems correct, trying to perform the previous cURL command from the bash shell of the machine on which WSO2 API Manager is installed I obtain a JSON response from the API, this:
{"timestamp":"2020-02-29T12:13:54.630+0000","status":404,"error":"Not Found","message":"No message available","path":"/puntualitest/v1.0.0/puntuali"}
It contains an error message but I think that it is cause by a "wrong" payload, anyway it seems that the final registered API endpoint received my request, elaboreted it and return me a JSON message (is it this reasoning correct)?
The problem is that trying to perform the request directly from the inside of the Store portal of WSO2 API Manager I am obtaining the following error message:
<am:fault xmlns:am="http://wso2.org/apimanager">
<am:code>101500</am:code>
<am:type>Status report</am:type>
<am:message>Runtime Error</am:message>
<am:description>Error in Sender</am:description>
</am:fault>
Reading on the documantation it seems to me that the error having code 101500 could be related to a certificate problem:
WSO2 ESB 4.9.0: what means error 101500
The previous link referer to ESB product and not API Manager but I suspect that the problem could be the same. I suspect it also because into my log file (/usr/lib/wso2/wso2am/2.6.0/repository/logs/wso2carbon.log) when I perform the previous request from the Store portal I obtain the following error message:
TID: [-1] [] [2020-02-29 13:34:58,686] ERROR {org.apache.synapse.transport.passthru.SourceHandler} - I/O error: Received fatal alert: certificate_unknown {org.apache.synapse.transport.passthru.SourceHandler}
javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:245)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:280)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:410)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:119)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:586)
at java.lang.Thread.run(Thread.java:748)
TID: [-1234] [] [2020-02-29 13:34:58,827] WARN {org.wso2.carbon.apimgt.keymgt.service.thrift.APIKeyValidationServiceImpl} - Invalid session id for thrift authenticator. {org.wso2.carbon.apimgt.keymgt.service.thrift.APIKeyValidationServiceImpl}
TID: [-1234] [] [2020-02-29 13:34:58,829] ERROR {org.wso2.carbon.apimgt.keymgt.service.thrift.APIKeyValidationServiceImpl} - Error in invoking validate key via thrift.. {org.wso2.carbon.apimgt.keymgt.service.thrift.APIKeyValidationServiceImpl}
TID: [-1234] [] [2020-02-29 13:34:58,830] WARN {org.wso2.carbon.apimgt.gateway.handlers.security.thrift.ThriftKeyValidatorClient} - Login failed.. Authenticating again.. {org.wso2.carbon.apimgt.gateway.handlers.security.thrift.ThriftKeyValidatorClient}
TID: [-1234] [] [2020-02-29 13:34:58,846] INFO {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - 'admin#carbon.super [-1234]' logged in at [2020-02-29 13:34:58,845+0100] from IP address {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil}
TID: [-1] [] [2020-02-29 13:34:58,941] ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O error: General SSLEngine problem {org.apache.synapse.transport.passthru.TargetHandler}
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1521)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:528)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1197)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1165)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:237)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:271)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:410)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:119)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:586)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1709)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:318)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:970)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:967)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1459)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:255)
at org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:293)
... 9 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:281)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1626)
... 17 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
... 23 more
TID: [-1234] [] [2020-02-29 13:34:58,948] WARN {org.apache.synapse.endpoints.EndpointContext} - Endpoint : SirPuntuali--vv1.0.0_APIproductionEndpoint with address https://ENDPOINT_IP_ADDRESS/cmd/j/ will be marked SUSPENDED as it failed {org.apache.synapse.endpoints.EndpointContext}
TID: [-1234] [] [2020-02-29 13:34:58,948] WARN {org.apache.synapse.endpoints.EndpointContext} - Suspending endpoint : SirPuntuali--vv1.0.0_APIproductionEndpoint with address https://ENDPOINT_IP_ADDRESS/cmd/j/ - last suspend duration was : 30000ms and current suspend duration is : 30000ms - Next retry after : Sat Feb 29 13:35:28 CET 2020 {org.apache.synapse.endpoints.EndpointContext}
TID: [-1234] [] [2020-02-29 13:34:58,949] INFO {org.apache.synapse.mediators.builtin.LogMediator} - STATUS = Executing default 'fault' sequence, ERROR_CODE = 101500, ERROR_MESSAGE = Error in Sender {org.apache.synapse.mediators.builtin.LogMediator}
TID: [-1] [] [2020-02-29 13:34:58,979] INFO {org.wso2.carbon.databridge.core.DataBridge} - user admin connected {org.wso2.carbon.databridge.core.DataBridge}
So it seems that WSO2 API Manager is trying to send the request to the correct endpoint but there is a certificate problem. Is it this reasoning correct?
If this could be the problem now I have some doubts about what I have to do to solve my problem:
Have I to obtain a certificate generated on the server hosting the final endpoint and have I to set it on my WSO2 API Manager or, on the contrary, have I to generate a certificate on the WSO2 API Manager machine and I have to provide it to the machine hosting the final API?
Reading on the documentation it seems to me that I have to obtain a certificate from the API hosting machine and I have to upload this certificate into WSO2 API Manager application (as shown here: https://apim.docs.wso2.com/en/latest/learn/design-api/endpoints/certificates/). But I am not sure of this assumption.
A self signed certificate is ok? In case what is the procedure to generate it and what kind of certificate I need to obtain (I have to provide precise information to the guys working on the final API machine)
Probably a trivial question: the Store portal is generating a cURL request using the -k option that is used to ignore certificate (infact performing it directly in the shell it seems to work fine). Why sending the request from the Store portal is not working? I suspect that it generates a cURL request for test pourpose but that under the hood the API Manager is not performing a simple cURL request.
The behavior is a bit strange. Just to explain what happens here, there are 2 HTTP calls involved.
The client (curl or UI) to the gateway
The gateway to the backend
As per the 2nd error trace, the problem is with the connection between the gateway and the backend. Answering your first question, to resolve this, you have to get the certificate of the backend endpoint and install it to the APIM's client-truststore.jks. You can either do it for each API via the UI, or you can directly install it to the jks file.
However, since this is independent of the client you use, you should see the same behavior for both cURL and UI. I don't get how it works for cURL.
Answering your 3rd question, the UI does not use curl inside to make the call to the gateway. And it has nothing to do with the above error either.
This is my basic mule flow:
HTTP Listener > Logger > Http Request > Logger (Result message)
<http:request-config name="HTTP_Request_Configuration" host="localhost" port="8080" doc:name="HTTP Request Configuration" usePersistentConnections="false"/>
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/>
<flow name="servoy-restFlow">
<http:listener config-ref="HTTP_Listener_Configuration"
path="/" doc:name="HTTP" />
<logger message="#[message.payloadAs(java.lang.String)]" level="INFO"
doc:name="Logger" />
<http:request config-ref="HTTP_Request_Configuration"
path="service/rest/request" method="POST"
doc:name="HTTP" />
<logger message="#[message.payloadAs(java.lang.String)]" level="INFO"
doc:name="Logger" />
</flow>
But it returns an error about timeout exception:
********************************************************************************
Exception stack is:
1. Timeout exceeded (java.util.concurrent.TimeoutException)
com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider:426 (null)
2. Error sending HTTP request. Message payload is of type: String (org.mule.api.MessagingException)
org.mule.module.http.internal.request.DefaultHttpRequester:287 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/MessagingException.html)
********************************************************************************
Root Exception stack trace:
java.util.concurrent.TimeoutException: Timeout exceeded
at com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider.timeout(GrizzlyAsyncHttpProvider.java:426)
at com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider$3.onTimeout(GrizzlyAsyncHttpProvider.java:274)
at org.glassfish.grizzly.utils.IdleTimeoutFilter$DefaultWorker.doWork(IdleTimeoutFilter.java:398)
at org.glassfish.grizzly.utils.IdleTimeoutFilter$DefaultWorker.doWork(IdleTimeoutFilter.java:377)
at org.glassfish.grizzly.utils.DelayedExecutor$DelayedRunnable.run(DelayedExecutor.java:158)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
********************************************************************************
What should I do to avoid the timeout?
The default timeout of http outbound request is 30 seconds specified in ms in mule. Increase timeout of http-request config to greater than 30 seconds, may be to start with 40 seconds and see what's your desired number.
<http:request-config responseTimeout="40000" .../>
Try increasing the timeout in:
<http:request-config responseTimeout="XYZ" />
Taking another approach to this problem...
Do you have an issue with the service you are trying to consume and it's not responding. I've always found the default timeout to be sufficient (even for calling external services).
You can set Timeout for your entire application configuring a global deafult timeout property at the beginning of your .xml, in example:
<configuration defaultTransactionTimeout="90000" defaultResponseTimeout="90000" doc:name="Configuration">
<default-threading-profile poolExhaustedAction="RUN"/>
</configuration>
I hope this helps.
Where you receive the POST request - maybe a method or microflow, there is actions that happen first and after that the POST is executed. If you cannot change the logic there and remove them, just increase the timeout in the request configuration in Mule.
What is an equivalent SWS call for the following host command:
PI/TRAVELER/823144910-1.1
I am trying to associate a guest profile with a guest on a PNR.
You also have the option to use SabreCommandLLSRQ to send the native PI/TRAVELER/823144910-1.1 command.
<SabreCommandLLSRQ xmlns="http://webservices.sabre.com/sabreXML/2003/07" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" EchoToken="String" TimeStamp="2001-12-17T09:30:47-05:00" Target="Production" Version="2003A.TsabreXML1.6.1" SequenceNmbr="1" PrimaryLangID="en-us" AltLangID="en-us">
<Request Output="SCREEN" CDATA="true">
<HostCommand>PI/TRAVELER/823144910-1.1</HostCommand>
</Request>
The only way to add a Profile Index (PI) to a PNR is to use the ProfileToPNR service that moves the profile into the PNR.