I want to record the requests while interacting with my server using an excel where it sends http request to the server. I have been using oracle openscript where i could easily configure my server name and the port it works on. Is there a way to do the same in loadrunner?
Record using Proxy Mode. The LR HTTP recording proxy will act as a man-in-the-middle for your connection from Excel to it's back end data source. Excel and the recording proxy need not be on the same host.
You can record in LoadRunner using Web - HTTP/HTML protocol. Within this protocol, you have got 2 options to utilize:
Record Windows Application.
LoadRunner Proxy Recording.
1. Record Windows Application:
Provide the path to the excel.exe and then start recording.
2. LoadRunner Proxy Recording:
Set a listening port for LoadRunner and then force Excel to send requests to the servers via this particular port.
Related
I love Fiddler, and it is a mainstay for my web debugging. It is working fine for all my browser based activities. But right now, I am having a login issue with CouchDB. I am using a desktop software called SAFE FME, which provides login and bulk upload to the CouchDB server. From the browser I can login to the CouchDB, so that did not seem the problem.
All I want to do is see the traffic going between the FME and the CouchDB server.
CouchDB is running on http://localhost:5984/
computer is windows 7, 64 bit. Both Couchdb and FME are local to the computer
I have Fiddler setup for:
Capture Traffic true
Any Process
Any idea why I am not capturing the data
You're probably not capturing the data because SAFE FME doesn't use the system proxy setting.
Open FME Workbench. From the menu select Tools|FME Options then select Network and check Use Proxy. Ref: https://knowledge.safe.com/articles/How_To/Configure-FME-Desktop-to-connect-through-your-proxy-server
The Fiddler proxy runs on 127.0.0.1 port 8888.
I have an SSL enabled Node server (v0.10.35) that provides the user with HTTPS and WSS connections. I would like to add a new SSL enabled WebSocket server to this configuration to allow me to connect a control application to the Node server, ideally using a different URL. For example:
Public Access : https://myserver (via Browser)
Control Access : wss://myserver/control (via my Software)
I am assuming that this can be done but I'll be honest I do not have a clue as to how to configure it, so I would appreciate help from those that do.
I don't know if it is worth while pointing out but my current implementation already supports WS to the Browser, this allows me to (obviously) send and receive messages.
What I would like to do is either add another WS Server to handle the control messages or configure my existing install to have multiple URLs so the browser would default to wss://myserver but the application would use wss://myserver/control for example.
I have a program in an embedded device that outputs an xml string to a socket. The embedded device has lighthttpd has a web server. I want to use a web based client (no flash/silverlight) to connect to the socket and pull the xml data every second.
I looked at Node.js with Socket.io to get what I want to do, but I am not clear about how to proceed. Searching through the Node.js and Socket.io documentation and examples I see standard client-server behavior, nothing regarding what I am trying to do.
Basically, the web server is just there to accept a connection from a client on the socket that the embedded application is outputting data to. Basically the web server's purpose is to just let the client retrieve data from the raw tcp socket that the embedded application is writing to. Please advice.
I solved the problem using Websockify, which acts as bridge between a TCP Socket and a browser.
The html client will connect to a websocket, and Websockify will listen on the websocket port and transmit data between the websocket and the tcp socket.
Web browsers have the ability to do HTTP requests (which can be web page requests or Ajax requests for data) and webSocket connections. You will need to pick one of these two mechanisms if you're sticking with stock browser access.
If the lighthttpd web server in the embedded device does not support webSockets, then your choice will like be an Ajax call from the browser to your server. This is basically just an HTTP request that make return something different than a web page (often JSON data) and is designed to fetch data from the server into a web client.
If the lighthttpd web server does support webSockets, then you could use a webSocket connection to fetch the data too. This has an advantage of being a persistent connection and allows for the server to directly send data to the client (without the client even requesting more data) whenever it wants to (more efficient for constant updates).
An Ajax connection is generally not persistent. A client sends an Ajax request, the server returns the answer and the connection is closed. The next request starts a new Ajax request.
Either Ajax requests or webSocket connections should work just fine for your use. All browsers still in use support Ajax. WebSockets are supported in modern browsers (IE10 and higher).
Once you decide upon a client connection strategy, then you'd build your web app on the embedded device that served as the middleman between the browser and the data on the embedded device. It would collect the appropriate data from the embedded device and then be able to send that to browser clients that connected and requested the data.
I'm not sure exactly why you mentioned node.js. In this circumstance, it would be used as the web server and the environment for building your app and the logic that collects the data from your device and feeds it to the requesting web browser, but it sounds like you already have lighthttpd for this purpose. Personally, I recommend node.js if it works in your environment. Combined with socket.io (for webSocket support), it's a very nice way to connect browsers directly to an embedded device. I have an attic fan controller written in node.js and running on a Raspberry Pi. The node.js app monitors temperature probes and controls relays that switch attic fans and node.js also serves as a web server for me to administer and monitor the node.js. All-in-all, it's a pretty slick environment if you already know and like programming in Javascript and there's a rich set of add-in modules to extend its capabilities available through NPM. If, however, your embedded device isn't a common device that there is already support for node.js on or it doesn't already have node.js on it, then you'd be facing a porting tasks to make node.js run on it which might be more work than using some other development environment that already runs on the device like lighthttpd.
What tool / function can we use on our linux server running CentOS to monitor the http headers that are sent from our application to another application on a different server? Looking for http header monitoring from server to server. My issue is I have no idea how to capture the data sent from the server, meaning the http headers sent via a post. I have tried many methods and third party software's like fiddler2 and ieinspector and the list goes on, but they only seem to capture the client headers and not what is being sent out from the server. I just need to capture the string being sent out via a post function and what is being returned. Seems simple, yet in this case, I'm beyond lost and running out of time to resolve what should be a simple solution. Please advise & thank you kindly.
I have a web application which is also displayed in a web browser control of a winforms application. MS Word and Excel are installed on Citrix server.
But I want to open a word/excel document on client's machine instead of Citrix server when I click a link on the website (which is displaying in web browser control)
Is it possible?
Citrix supports a mechanism called Content Redirection which can redirect specified filetypes either to server or to client.
See this Server-to-client Content Redirection Explained for an explanation.
In order to communicate with the client computer, you will need to have software running on the client computer to accept and interpret commands from the hosted application.
We had something similar here. Clients needed a way to print to a special printer (for whatever reason the printer was not compatible with citrix). We had to create a "listening" app for the client computer and modified the hosted app to send commands via winsock\tcpip. So when a print job was requested, the hosted app sent command data to the listening app on the client and the client actually started the print job.