I am new worklight . I am using this WL.Client.invokeProcedure.What is the third parameter(useSendInvoke) in the WL.Client.invokeProcedure.
See this question about useSendInvoke: Use of third parameter in the WL.Client.InvokeProcedure
To quote Anton:
This parameter is used internally by WL authentication framework.
Technically there should not be a reason for developer to use it.
There are several ways to invoke adapters.
(1) First one is via client application. This is where you use
WL.Client.invokeProcedure(invocationData, options) API.
(2) Second is by using adapter invocation service -
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fc_adapter_invocation_service.html.
Basically issuing an http request to WL server and getting a response
from adapter. RPC style.
When you're doing it via (1) - you have two authentication layers -
first is security test defined for application, second is security
test defined for adapter procedure.
When you're doing it via (2) - there is only one security layer -
security test defined for adapter procedure.
UseSendInvoke param (which is, once again, for internal usage) means
that your application will go via path (2) instead of regular path
(1).
Related
I am exploring Karate API double (mocking) for the integration test. For the below scenarios, I'm not getting the expected mocking response. Your help will be appreciated.
My Setup :
1. Karate Mock Server up with pathMatches rules on port 8001: http://localhost:8001 ( working, validated against "/cat" and some test calls)
2. My own Application is up from docker on port 8080. From Docker exposed 8001 port as well.
Mocking Case:
1. My application REST call exposed to all users http://localhost:8080/service/v1/findUser. This exposed API, underlying calling other REST call http://dev-STG/userservice/v1/findUser which actually giving JSON response. So, I want to mock underlying API call and validate my API behavior accordingly.
Steps tried:
1. Now, in my application config, m replacing actual underlying API call to Karate mock server(http://localhost:8001/userservice/v1/findUser). Then did build & up my application docker.
In Karate, I defined test e.g "testIntgrtn.feature" which calling my application API "http://localhost:8080/service/v1/findUser" and Karate mock server up and set with pathmatch "/userservice/v1/findUser".
After executing "testIntgrtn.feature" karate not mocking for an underlying call(http://localhost:8001/userservice/v1/findUser).
Now, in "testIntgrtn.feature" file I changed my-application URL to underlying REST URL i.e (http://localhost:8001/userservice/v1/findUser) then mocking will work like charm.
I'm not understanding why underlying API call not getting mocked here? Did I miss something here?
Also, in Karate can we monitor all REST calls (like cypress mocking).
Thanks for this wonderful framework. Which is intuitive for writing automation cases.
Karate cannot automatically intercept calls.
The recommended approach is when you boot the application running at localhost:8080 you change the configuration so that instead of calling http://dev-stg/userservice/v1/findUser it calls something like http://localhost:8001/v1/findUser. This is what most teams do, and is easy because you should anyway be defining external URL-s as application.properties (or equivalent) as a best-practice.
It is very easy to over-ride an application property in Spring Boot for example, you can do this via the command-line: https://stackoverflow.com/a/37053004/143475
If you want, you can dynamically provision a port for the mock. So your unit test can first start a mock, get the port, and then start the server. You can find details in the Karate documentation.
All this said, if you are able to change the (system) HTTP proxy before the app at localhost:8080 starts, you may be able to do this without modifying the configuration. (But it is tricky, so I recommend the approach explained above.) So in this case, Karate can actually "intercept" the outgoing HTTP calls that the app at localhost:8080 makes.
See the second-last row (5a) in the table here: https://github.com/intuit/karate/tree/master/karate-netty#consumer-provider-example
I am exploring Karate API double (mocking) for the integration test. For the below scenarios, I'm not getting the expected mocking response. Your help will be appreciated.
My Setup :
1. Karate Mock Server up with pathMatches rules on port 8001: http://localhost:8001 ( working, validated against "/cat" and some test calls)
2. My own Application is up from docker on port 8080. From Docker exposed 8001 port as well.
Mocking Case:
1. My application REST call exposed to all users http://localhost:8080/service/v1/findUser. This exposed API, underlying calling other REST call http://dev-STG/userservice/v1/findUser which actually giving JSON response. So, I want to mock underlying API call and validate my API behavior accordingly.
Steps tried:
1. Now, in my application config, m replacing actual underlying API call to Karate mock server(http://localhost:8001/userservice/v1/findUser). Then did build & up my application docker.
In Karate, I defined test e.g "testIntgrtn.feature" which calling my application API "http://localhost:8080/service/v1/findUser" and Karate mock server up and set with pathmatch "/userservice/v1/findUser".
After executing "testIntgrtn.feature" karate not mocking for an underlying call(http://localhost:8001/userservice/v1/findUser).
Now, in "testIntgrtn.feature" file I changed my-application URL to underlying REST URL i.e (http://localhost:8001/userservice/v1/findUser) then mocking will work like charm.
I'm not understanding why underlying API call not getting mocked here? Did I miss something here?
Also, in Karate can we monitor all REST calls (like cypress mocking).
Thanks for this wonderful framework. Which is intuitive for writing automation cases.
Karate cannot automatically intercept calls.
The recommended approach is when you boot the application running at localhost:8080 you change the configuration so that instead of calling http://dev-stg/userservice/v1/findUser it calls something like http://localhost:8001/v1/findUser. This is what most teams do, and is easy because you should anyway be defining external URL-s as application.properties (or equivalent) as a best-practice.
It is very easy to over-ride an application property in Spring Boot for example, you can do this via the command-line: https://stackoverflow.com/a/37053004/143475
If you want, you can dynamically provision a port for the mock. So your unit test can first start a mock, get the port, and then start the server. You can find details in the Karate documentation.
All this said, if you are able to change the (system) HTTP proxy before the app at localhost:8080 starts, you may be able to do this without modifying the configuration. (But it is tricky, so I recommend the approach explained above.) So in this case, Karate can actually "intercept" the outgoing HTTP calls that the app at localhost:8080 makes.
See the second-last row (5a) in the table here: https://github.com/intuit/karate/tree/master/karate-netty#consumer-provider-example
Relay.injectNetworkLayer(
new Relay.DefaultNetworkLayer(${GRAPHQL_SERVER}/graphql)
);
So How can I know graphql server has successfully injected this remote graphql server or not ?
You can check if there is a network layer implementation set via Relay.Store._storeData._networkLayer._implementation. If this is defined, your network layer has been injected. Fair warning, the underscore prefix tells me this is an undocumented API and is subject to change at any time.
I'm trying to make a simple example of a connection to a WS (JAX-RS), when I call from the browser, I should return a string but I get the following error message:
missing_authorization, this is the URL to access the resource (REST):
http://localhost:10080/PruebaWSProject/adapters/MyAdapter/users/pramirez
When I test it directly from MobileFirst Studio using "Call MobileFirst Adapter", it works perfectly.
It seems to be a problem with HTTP authentication, apparently I have to set something in the XML file server: authenticationConfig.xml, but I do not know what I have to put and I read the following in a web:
Disabling the authentication requirement for a specific procedure.
You can do so by adding the securityTest="wl_unprotected" property to the element in the adapter XML file.
I do not know how to turn off the security to call the resource to obtain the chain. The name of the classes generated by the Java adapter are: MyAdapterResource and MyAdapterApplication.
Java Adapters are protected by default.
When you use "Call MobileFirst Adapter", a test token is automatically added to help you preview.
If you want to test your adapter outside of the wizard, you have 2 main options:
Disable security by adding #OAuthSecurity(enabled=false) before your procedure code (in MyAdapterResource). Keep in mind that your procedure will no longer be protected. See Protecting Adapters.
Generate a test token manually. You can request a test token which you will add to your HTTP headers. See In Postman
The instructions you saw regarding securityTest="wl_unprotected" are for JavaScript adapters, not Java.
Hi i am new to worklight. When i am trying to invoke the adapter using the client side call. There is a parameter in the invoke procedure api call.The parameter is useSendInvoke .What does that mean?
See this question about useSendInvoke: Use of third parameter in the WL.Client.InvokeProcedure
To quote Anton:
This parameter is used internally by WL authentication framework.
Technically there should not be a reason for developer to use it.
There are several ways to invoke adapters.
(1) First one is via client application. This is where you use
WL.Client.invokeProcedure(invocationData, options) API.
(2) Second is by using adapter invocation service -
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fc_adapter_invocation_service.html.
Basically issuing an http request to WL server and getting a response
from adapter. RPC style.
When you're doing it via (1) - you have two authentication layers -
first is security test defined for application, second is security
test defined for adapter procedure.
When you're doing it via (2) - there is only one security layer -
security test defined for adapter procedure.
UseSendInvoke param (which is, once again, for internal usage) means
that your application will go via path (2) instead of regular path
(1).