I have shared folder between in my server which will allow other server to send XML file to me and I want my script read this file auto without opening any page.
I know how to open and read the file.
But the issue how to auto load in the backhand.
you have to create a one page which will read the provided file and do the required actions , then share this URL and format with the team who will going to provide you the xml file.
It is very much like API Endpoint, Where you have to write the code which will handled request and in this scenario your Endpoint will treat as a server and XML file provider will treat as clients.
I hope this answer helps u.
Thanks
Traditionally, you need your server to periodically execute the script which reads the XML. That PHP will need to parse the XML and handle the changes.
Alternatively, the source of the API can use push notification to avoid polling with your server. The XML will be received whenever a change occurred on the server without the creation of a lot of useless requests, but the XML will be parsed as in the previous approach.
Last, but not least, you can use WebSockets for this purpose, or if both computers are in the same network, you can use sockets. Off course, a lot depends on the data source, whether you have access there, how modern is its technology and what does it allow you to do.
Related
This is my situation:
I have a third part that uses a software called microstrategy which is able to generate documents and allow to export them as PDF or Excel files. They provide me only web api of this product, and I haven't any web service to work with.
The url is like:
http://<third_part_domain>/microstrategy/asp/Main.aspx?Server=<third_part_domain>&Project=<project_name>&evt=3069&src=Main.aspx.3069&executionMode=3&promptAnswerMode=1&documentID=<doc_id>&uid=<username>&pwd=<password>&<other_parameters_for_request>
I have try to obtain the file (that I must save on server side) by java code, but the response of the link that we use is an HTML page with some code Javascript that does more than one redirect, so I can not interpreted correctly the response and I should use a browser to obtain the PDF.
So I have thought to put the page into a iframe and after a while (usually the server takes 20 second) take the PDF object by javascript code and send to my server. But obviously the third part have another domain and the CORS policies block everything. To make matters worse, I can not use the final url to obtain the file because the microstrategy respond me with an internal page of the administration console.
So, that's my question:
Is there a way (that is not on the microstrategy server side) to obtain directly the PDF from microstrategy?
Or exists a way from client side to bypass the problem of origin control? I have evaluated to implement a proxy for solution but it's too expensive.
Thanks to all!
You need two things in order to download a PDF from MicroStrategy using a URL:
In the document property set that default visualization as PDF. This is pretty trivial and I think any of your MicroStrategy savvy colleague can help you with this.
Disable the waiting page, this is more complicated. When MicroStrategy generates a documents, usually it needs some time, meanwhile the server is working it will show you a waiting page. Useful if the request comes from a human (the human can go on StackOverflow), not that much if the call arrives from API.
The instruction to disable the waiting page are here: TN34124: How to Disable the Wait Page in MicroStrategy Web using the MicroStrategy Web SDK 9.x.
But I read from your question that you have no control on the third party MicroStrategy application. In that case there is little you can do. You can try to ask them to implement the customization to remove the waiting page or allow you to use taskproc API, but that's a story for another day.
Some options:
Ask the third party to schedule the PDF generation on their side and send it via mail to you. Or place it on a shared folder that is shared between you.
Ask for a different URL Tuareg from the file-share menu options. This will give a URL with 'subscriptionid' in it.
No matter how much I look this up all I get is the w3C File API which focuses on local files for the client.
What I'm trying to do is I have a server. I'm trying to use client-side javascript to grab the server hosted text file, a.txt, and display it to the innerDOM of an html page. My server directory look like this:
index.html
read.js
text files
a.txt
All I want to have happen is for, on the client side, the javascript read.js running in the index.html on onload to display the contents of a.txt. I figure that since a.txt will never be large, leaving it to the client is fine.
But I can't figure out how to do this and the W3C File API isn't offering me answers.
If I had to guess, somehow making sure index.html loads a.txt and then grabbing that via the file API might be the way to go but I'm not sure how to do that.
And I'll admit it, I'm a bit of a noob. If I'm invalidating browser sandbox or doing something impossible, please tell me. I just thought this would be so simple.
Also, I'd appreciate that if you were going to suggest AJAX, either don't, or explain it like I'm a baby because I really don't know.
Thank you all so much for your help.
Why file API is irrelevant:
Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application.
From W3C File API.
So, File API is intended to be used to allow users to upload files from their clients into the server. On the other hand, AJAX is used to allow users to download files and other data from the server into their clients. And this is exactly what you need.
Refer to jQuery's ajax documentation.
I believe this page should help you out with your problem.
http://www.htmlgoodies.com/beyond/javascript/read-text-files-using-the-javascript-filereader.html#fbid=YhNukIHynD3
I would suggest using an Ajax call to the file on the server, since the response of the call will typically be the contents of that file.
Using Jquery this can be done by a simple
$.ajax({ 'url':'a.txt',
'success': function(r){
//display to innerDOM here, using r as the file
});
});
You simply want to display a txt file on the web page?
Do you know about server side includes?
That would be one possibility if you control the server.
If you really want to do it in javascript, then AJAX would be the way to go.
If it were me at that point I would figure out how to include and use jQuery to help with the ajax bits.
You will simply request the text file via its URL (you can get it to load in the browser right?), and then use jQuery to put that text into some DOM element.
Does it send an HTTP GET request for the specified file? I'm trying to write my own NodeJS webserver, and want to know how to go about dealing with sending the browser the javascript files it needs.
Let's say I'm using several javascript libraries for a web-app I'm building, and for each of them I have a script tag in the head of my HTML file (e.g. <script type="text/javascript" src="jquery.js"></script>). In my server, would I be able to code something up to call different functions based off of the src requested, and to return a file that isn't necessarily in the same location that the HTML would make one expect it to be?
I'm still new to NodeJS and webservers in general, so I apologize if this is really obvious to other people out there...
Does it send an HTTP GET request for the specified file?
Yes.
I'm trying to write my own NodeJS webserver, and want to know how to go about dealing with sending the browser the javascript files it needs.
Then don't worry about how the browser decides what HTTP requests to make. Just implement the HTTP specification.
In my server, would I be able to code something up to call different functions based off of the src requested, and to return a file that isn't necessarily in the same location that the HTML would make one expect it to be?
This sounds like you are planning to serve up different content for the same URI based on the referer header … I'd expect this to hit a cache and turn into a race condition based nightmare. Don't do it. Write your HTML so if you need different scripts, you request them from different URIs.
If, on the other hand, you mean that you want to return data without reading it out of a file on the file system, then that is fine. Clients don't care how the server determined what data to put in an HTTP response. Just make sure that it is sane and consistent.
Does it send an HTTP GET request for the specified file?
Yes.
You don't have to worry about when and how the resources are requested from the browser, just map the resource addresses that you want to make available to the content that you want to return for each resource.
would I be able to code something up to call different functions based off of the src requested, and to return a file that isn't necessarily in the same location that the HTML would make one expect it to be?
Of course. There is no direct relation between the address of a resource and the physical file where you get the data for the resource, there is always some code that does the mapping between the resource address and where the data is fetched. It's just easier to manage resources when the files are arranged in basically the same hierarchy as the resource addresses.
Does it send an HTTP GET request for the specified file?
As Quentin said, Yes the browser will request each script file specified in the source HTML with a GET request for that particular URI.
When your web server receives that GET request, you can do anything you want to return data for the URI request. You do not have to actually return a file from that path. In fact, you can parse out the path and use the different parts of the path as data parameters in the request (that's what a lot of web apps do these days).
So, if the request comes in for http://www.mysite.com/user/john/accountnumber, you could look up in your database and fetch the account number for a user named "john" and return that data. The result does not have to come from an actual file or from anything that actually has that path.
This is a followup question to the one here
Here's briefly what I am trying to do. The File server creates a text file to indicate an end of the process. On a webpage on the Web Server, I loop every x seconds and make an ajax request to find out if the test file exists (ajax request to http://fileserver/files/UserFile.txt)
I've tried the following approaches so far:
Trigger a web method from the client side that creates a HttpContext object to verify if the text file exists. But this is too strenous on the server and I started getting all kinds of exceptions in the Event Viewer.
YQL works great but unfortunately it's too slow. The user waits atleast twice the amount of time.
I am looking for a solution that doesn't involve the server side. Somehow, I'd like to use JQuery to verify the existence of a text file on the fileserver.
Any thoughts?
You should be able to use JSONP and JQuery.ajax() to do cross-domain request work. Play with the jsonp and jsonpCallback attributes. Alternatively, you can use JQuery.getJSON().
Serving a single file from the filesystem is the most simple operation a web server can do. If that is already too much, then all other solutions will be worse. Find out why the server takes so long to serve a simple file and fix that.
Note: I'm assuming that the file is small since you say "test file". If it's a big file, the server will actually send it to the client which will need a lot of resources.
What you can try is to add an ASP page to the web site which runs code on the server that checks whether the file is there and just returns a tiny piece of HTML which you can add to the page with jQuery.load().
I may be miles off base here but... could you not create ONE asynchronous (!) Ajax client request with a HUMONGOUS timeout. Fire it, and wait. You would be invoking some server script that checks every so often, in a loop on the server (using sleep in between), whether the file exists. And not replying to the Ajax request until the file finally shows. The server script then replies and exits.
EDIT: Depending on the server-side scripting framework used, you may even get some OS support. You may be able to sleep on a status change in the directory...
There is this 3rd party webservice. One of the public webmethods available is a GetDocument() method. This method returns a Document object. The Document object has properties for File(byte[]), ContentType(string) ect.
My Question : Can I subscribe to this service using javascript(mootools) + ajax + JSON, return the document object, in this case an excel document, and force the file download?
It is true that typically you cannot initiate a download from JavaScript, but there is a flash component, Downloadify that does enable client side file generation.
So you can serve files for download from HTML/JavaScript.
With that problem solved, you still have the problem of how to get the data that you wish to serve from the source web service.
3rd party implies XSS (cross site scripting) which is a no-no using XmlHttpRequest (Ajax).
A possible solution to this problem could be to use a common hidden IFrame technique to get the data.
Simply have an appropriate (hidden?) form that correctly posts to the web service and point it's action to an hidden IFrame element upon which you are trapping the Load event and parse the data returned.
But current browsers have different levels of security measures that limit your ability to access IFrames with an external source so you are actually stuck here. Sorry to get your hopes up.
The only practical robust way to accomplish what you would like to do is to have a local server side script that can act as a proxy between your HTML/JavaScript and the external web service.
Using such a proxy, you can simply go back to using Ajax to get your data to serve up with Downloadify.
But then, since you are using a server script to get the data, why not just serve the data from the script for download?
These are just my observations on the problem domain you present.