I have a NodeJS application, from where I'm supposed to use web service (that support only soap) through soap calls.
The biggest problem is, that the Web Service doesn't have a WSDL api description anywhere. So my question is, how could I call servoce methods with NodeJS, use Soap without WSDL.
I have seen some solutions like use of require module.Installed the same(npm i require).Able to set headers and other options but dont know how to call the methods.
Thanks for any help.
How do you know a method to call and types and a number of parameters and return value without WSDL?
SOAP is a self-descriptive protocol that's why you can (and you should) use WSDL to get the whole description of what a certain service provides to you. All SOAP services normally have a rule that you can add '?wsdl' (or something similar) at the end of a service url to get WSDL.
You can try to construct a HTTP request by hand but it's worthless cause you will spend a lot of time to implement all method calls and to take into account types of parameters, their restrictions and structure and so on.
I think I just need a pointer in the right direction.
I am testing an application server (through its REST API). I'm using cucumberjs
When I invoke a specific method, some time later the application will send a notification to a URL. The URL is configurable, but only in the app settings - i.e. I can't give a callback URL for each invocation.
In my test step, I need to wait for (and receive) that notification, and extract some data from the request body to use in later steps.
How do I go about this? I guess I could set up a web server for each scenario, pass it a reference to my World object, and have it update something there with the details of the notification (it's OK to configure the app settings to point at my testing app).
But how do I wait (with a timeout) for the notification to be received?
(Ideas, and pointers to doc I should have found, suggestions for node.js packages etc. all welcomed)
I am performing similar types of testing where I need to trigger something in a could-based system and then wait for some behavior to occur. In order to achieve this, I'm using the promise-retry NPM package to perform polling (when needed) and then configuring the default timeouts in CucumberJS to be higher than normal (usually around 60 seconds). I also use config to make all these timing configurations easier to manage.
As far as how you're interacting with your system, it depends on what type of system it is. If you're using Azure, AWS, or Firebase there are API clients that they provide.
If you need to poll, I would recommend a promise-based HTTP client like flashheart, axios, or superagent. CucumberJS itself does not provide these capabilities, but it's easy to bring in other modules for CucumberJS to integrate with.
If you want to receive notifications directly, you could use some sort of cloud-based event hub like Azure Service Bus. Alternatively, if your tests are running on the same network as the system you could easily run an Express HTTP server within CucumberJS. As you receive messages, push them onto an array and then have a step definition to assert that the array contains the expected message.
"API" seems to have two completely different meanings in "Fetch API" and "REST API". The former being a method to fetch data from a server - the latter being some server that you can fetch data from.
API stands for application programming interface. It is something that a program can programmatically "talk to" to get data or make something happen. That can be local within a specific programming environment, like the fetch API of Javascript, or it can be a remote API you can programmatically send a network request to. The principle is the same in both cases, a defined interface you can contact in a specified manner to make specific things happen.
API stands for Application Programming Interface. The term API always means the same in these various instances, however there many types of API that define different methods of communication/interaction between software/program components.
So in the case of a REST API it is not a server that you fetch data from, it is (just like the Fetch API) a way to fetch data from the server. The API provides an easy way to communicate with the server that contains the data.
Is there any way I can access the chrome.* apis (specifically chrome.history) from a Web Worker?
If I pass the chrome.history or chrome object in with postMessage, it is not working because of a conversion error to Transferable type.
I can successfully query the history from my extension and pass the results, but I would like to leave the heavy lifting to the worker instead of the main thread and then pass the results.
Web Workers are meant to be light-weight, and do not inherit any permissions (not even host permissions) from the extension (besides, chrome is not even defined in a Web worker).
If you're doing really heavy stuff with the results of the chrome.history API, then you could pass the result of a callback to a worker for processing (with Transferables, the overhead is minimal). Before doing that, make sure that you profile whether the performance impact is really that significant to warrant implementing anything like this.
I am looking at express.js for the back end and JS on the client side.
My app is a single page Web App.
The server will only serve JSON messages and my question is about "routing" for express.
Is one supposed to use routing to connect the UI and the server side business logic?
How will that work with my single page app?
so lets say, the client makes an Ajax call to the server looking for a value in the database and there is server side script that provides the JSON back to the UI. How is this UI and node script relationship setup?
Can someone shed some light on this?
Single page apps are those that live on a single HTML document. This means that if you want to display some different content to the user, depending on the state of the application, you will need to do some DOM manipulation (cutting out and replacing certain elements of the current document with different HTML) in order to update the 'view' that the user sees. Excuse me if this is obvious to you, please don't take offense. I figured I'd start from here. Hang with me and I'll explain how your routing situation is going to play out (more or less).
URLs are composed of a few different parts, each of which informs the browser of a particular bit of information that is required in order to download the resource that the user is attempting to access. Typically the resources that you are looking for are off on a server somewhere and the browser knows this because of pieces in the URL like 'protocol' ('http:') and 'host' ('www.mydomain.com'), so it goes off to that server to find what you're requesting. There are also 'query' parameters in URLs which provide some additional information to the server regarding a particular action, like the search terms of a search query. After the query parameters, comes the 'hash'. The hash is where the magic of single page apps happens... eh, well, kind of.....
First a bit about the hash. When you add a '#' to a URL, the browser then interprets the information that comes after it to be some location (element) within the currently displayed document. That means, if you have an element with an 'id' of 'main' and you add '#main' to the end of the URL, like so: 'http: //www.example.com#main', the browser will 'scroll' (typically 'jump') to the beginning of that element, so that the you can see it. Be aware, though, that if you type 'http://www.example.com/#main' (with the hash separated from the URL by a slash) then you will force a complete page reload and the browser will attempt to find a file by the name '#main' on the server (I bet it doesn't find it).
The takeaway here is that the browser will not attempt to navigate away from the current document if there is a hash in the URL, the exception being of course the case mention above, and this is great because single-page apps don't want to navigate away from the page or request a new document from the server. (See how routing is different for single-page apps?)
Now, this whole thing about the hash isn't vital to single-page apps, as you could make one without dealing with it all. A bunch of click handlers and DOM manipulation is all you'd need really... But, that would mean that users will have no way of sharing links to particular views in your app. The URL would never change, and we would never be able to navigate to any particular view directly. We'd always be starting from the starting position of your app, which could easily be a very annoying situation.
If your single-page app is going to have different views, and you want users to be able to navigate directly to particular ones via bookmarks or links, then you will need to implement a form of routing on the front-end in addition to the routing that you'll need to implement on the backend (routing for data API, etc.), which means that you will need to make use of the hash.
I don't want to get into how different frameworks accomplish routing on the front-end, but it's basically a matter of updating the browser's address field when the user clicks a link, and watching the address bar to determine what the current URL is and loading the HTML that is associated with that URL into the DOM in the designated location in the document tree.
So, within a single-page app, you have one route on the server that deals with rendering the app HTML document (index.html), and you have routes that are responsible for dealing with the data of your app (creating new instances in the database, logging in and out, editing or destroying instances in the DB, and fetching data...) which are called via AJAX requests.
This is actually a fairly complicated situation in that HTML5 allows us to be able to forgo the hash (with the help of some link rewriting on the server) and also be able to use the 'back' and 'forward' buttons as if we've actually navigated away from the original document (which we haven't because we have only pointed the browser to the exact same URL, only with modified hash values, so no new page loads have occurred). Traditional site navigation and linking can be achieved by utilizing the browser's History API, which is available for IE beginning with version 10 (I believe), the rest of the big browser vendors were already on to it quite a bit earlier, so frameworks that leverage this technology will allow your users to navigate your app without the hash in the URL. Explaining this is a diversion and not necessary for understanding routing in single-page apps, but it is interesting and you'll have to learn it eventually anyway, probably..
AJAX should be used to request JSON from the server. AJAX requests will always hit your server because you don't include the hash symbol in AJAX requests (it would be ridiculous to do so because the hash is meant only for in-document browsing), so server-side routes must be responsible for exposing your data API (consider a RESTful one). While this is not their sole purpose in single-page apps, it is perhaps their most important one.
Soooo, to wrap it up, you will have two sets of routes. One on the client (as part of a client-side framework like AngularJS or EmberJS, the list goes on... I prefer Angular, but there is a fairly steep learning curve for that one.), and one on the server. When you think about 'server routes' think data API. When you think of 'page routing', remember that this all gets handled on the client, by the javascript that you delivered with the initial server response (this is the one and only necessary server-side route involved with rendering HTML to the browser, loading your 'index.html' and all of the necessary scripts and stylesheets, etc). You will use express.static middleware to serve static files, so you don't have to worry about assigning routes for that stuff.
EDIT A quick mention of AJAX implementation.
On the server, you will have routes similar those that Alex has provided as examples and you will make calls to those URLs from the client using whatever XMLHttpRequest (XHR) object is exposed by your framework or library of choice. It is now considered more or less standard and best practice for frameworks/libraries to implement these requests as Promises http://wiki.commonjs.org/wiki/Promises/A. You should read a bit about it on your own, but I might be able to summarize it by saying that it is an asynchronous operation analogous to 'try, catch, throw' in synchronous operations. You will instantiate a promise object and through it you will attempt to load data from the server, for instance, via GET request. Make sure that you have assigned functions to handle requests made to the URL that you made the request to (server-side route)! This object that you instantiate and subsequently make the request to the server through, promises to return the result of the request to you once it comes back from the server (no matter whether it was successful or not) If it is successful, it will call a function that you have written and will supply it with the data from the server. If it fails, it will call a different function, also written by you, and will supply it with the error object (or 'reason' for failure), so you can handle the error appropriately.
Hope that helped answer your question.
You only have to route requests you serve dynamically. Your HTML, CSS, JS are all static assets. So all you need to handling routing for is your data.
It sounds like you want a Restful API, which basically means that you have URLs for specific resources, and HTTP verbs for manipulating them.
Something like:
GET /books.json - Get all books
POST /books.json - Create a new book with properties passed in the body of the request
GET /books/123.json - Get book with id of 123
PUT /books/123.json - Update an existing book with properties passed in the body of the request
This blog post seems to show how to set this up in Express.
Once you have a sane API delivering JSON, you just make your AJAX calls use it based on what objects you want to fetch.