Hello to all the community. Within the Metatrader platform, there is a way to create accounts once the desired broker has been selected. My problem arises when I want to automate this process from code. From my search on the internet I understand that the solution could be using the .crv / .dat files, from within the config folder where said platform is installed, which contain the necessary information. But unfortunately it hasn't worked for me because I don't even know how to read them.
Specifically, I would like to know if there is any API that allows me to carry out the explained process (account management), as well as consult information (account balance, trades ...) which is also shown on the platform. Currently I am only interested in demo type accounts.
The closest solution I've found is using this API, but it's not free and also doesn't work for all brokers.
There is basically no solution to register demo accounts for any broker this way as not all brokers support registering demo accounts via MT terminal.
If a broker allows creating demo accounts via MT terminal, then it is also possible to register a demo account via MetaApi MT account management api.
For most applications the revenue application owner will earn per demo MT account is much higher than a fee MetaApi charges for API use, thus the fee just makes sense. It allows the MetaApi team to continue working on the project while not reducing application owner earnings significantly.
However if your application is low margin then you might want to automate it yourself. In this case you will also need to spend either time or money or both to implement your own solution.
Related
What considerations are needed when creating a web app that is intended to be used in an industrial plant setting for a company? My specific use case is an industrial facility with several different production plants that would each have its own device for the application interface.
How do companies enforce the usage of such apps on a monitor/tablet? For example, could I prevent them from using other stuff on the tablet?
Importantly, how would security work? They'd share a device. There may be multiple operators that use the app in a given shift. Would they all use the same authentication session (this is not preferable, as I'd like to uniquely identify the active user)? Obviously I could use standard username/passwords with token based sessions that expire, however, this leaves a lot of potential for account hijacking. Ideally, they'd be able to log on very quickly (PIN, perhaps?) and their session would end when they are done.
As long as there is internet connection, I would presume that there isn't much pro/con regarding the use of native applications versus web based or progressive web apps. Is this assumption correct?
What's the best way of identifying which device the application is being run on?
Is this a common thing to do in general? What other technologies are used to create software that obtains input from industrial operators?
--
Update - this is a good higher level consideration of the question at hand, however, it has become apparent why focused, specific questions are helpful. As such, I will follow up with questions that are specific.
Identifying the Area/Device a Web Application is Accessed On
Enforcing Specific Application Use on Tablets
Best Practices for Web App Authentication in Industrial Settings
I'm not able to answer everything in great detail but here are a few pointers. In the environment as you describe we usually see these two options. 1) you tell them what you need, internet, security, if they give you device and how it will be configured 2) they tell you exactly what you need to deliver.
I do not think you can 100% prevent them. We did it by providing the tablet( well laptops in our case) and the OS configuration took care of that, downside we had few devices to support. You seem to hint that there is always an internet connection so I guess you can collect all info about the system and send it back to you daily?
We were allowed to "tap" into their attendance SW and when you entered the facility you were able to use your 4 digit pin to log in if you were out of premisses you could not log in at all. I can imagine the following: you log in with your username and password - this does full verification, after that, you can use 4 digit pin to login for next n hours.
maybe, kinda, depends on what you are doing. Does the browser have all features you need? Our system needs multicast to perform really fast, so we have a native app
touched on this in 1. You could also use device enrolment process. You can also contractually force them that there will be only your software and it may invalidate support contract. It really depends on your creativity. My favourite( and it works - just tell them, there will only be installed my software and if not you will pay me double for support. I only saw one customer who installed some crap on the device when there were told not to
it really depends on what industry you are talking about, every industry is different. We almost always build a custom solution
The enforcement of the device/app usage depends on the customer, if the customer asked for help in the enforcement, then you can provide guide, training and workshops. If the customer serious about the enforcement then it will be a policy that's adapted by all the organization from top to down. Usually seniors will resist a workflow change more than juniors, so top management/executive should deal with that. Real life story: SAP team took 6 months to transform major newspaper workflow, during that few seniors got fired because they refuse to adapt the change.
Security shouldn't handicap the users, usually in industrial environment the network is isolated or at least restricted through VPN to connect multiple sites (plants in your case), regarding the active user: we usually provide guide/training/workshop for the users and inform them that using colleague account or device will prevent the system from tracking your accomplishment/tasks, so each user is responsible to make sure the active account/device is the one assigned to him/her.
It depends, with native you have more controls than web, but if the app is just doing monitoring then most of today apps use web for monitoring and the common way to receive input is REST APIs (even if the industrial devices doesn't support REST API, a middleware could be written to transform the output). If you need more depth about native vs web you need to ask new question with more details about the requirements.
Depends on the tech you are using (native or web), and things I mentioned in point 2: you can use whitelist of devices that's allowed to run the app. overall there are many best ways to track down the device.
How common in general? I think such information can only be achieved by survey, the world full of variations. And having something common not mean its safe or best, our industry keep changing at all levels. So to stay in the loop, we must keep learning and self-updating without reboot.
Long time ago, I took and passed the Google Analytics IQ certification test. At the time, I don't believe there were such things as Core Reporting API, Management API, and Metadata API (and probably some other Google Analytics related API's that I don't know about). Now that I am going through the Google Analytics IQ certification training course again (provided by Google, presented by Justin Curtoni?? I believe that's his name), I found that they now have Core Reporting API, Management API, and Metadata API.
I am a computer programmer by trade; so, I have no problem with programming using these API's. However, what I don't understand is, what do these API's buy me that the Google Analytics UI cannot offer? There is no reason to write a program that utilizes these API's simply because I can do it. To me, the existing Google Analytics UI has a lot of tools, reports, and other features that quite extensive. I am hoping that some of you can help me see something that I am probably missing.
The APIs are primarily for programmatic access. For example, if you need to create 1000 accounts all with the same property/view structure and then maybe add a few view filters to each of those accounts, you'll probably want to use the Management API. Doing that by hand would be a nightmare.
The same thing is true for the reporting API. Maybe you want to set up task that runs every monday morning and reports on the previous weeks data. And maybe you want to display that data on an internal dashboard for your company using some fancy charting library. You'd have to use the API to get the data.
Dashboards (executive summaries; managers often want nice visualizations instead of boring drill-downs)
Custom reports for user groups that do not have a Google Account or are not supposed to have access to full reports (e.g. Affiliates)
advanced filtering and aggregation (GA report cannot do everything)
You can combine analytics data with external data (e.g. you are not allowed to store personally identifiable information within GA; but you might store a custom key that allows you to link analytics data to customer data from you CRM or fulfillment system)
Machine-to-machine communication; I once did tracking for an airline that needed trend data on what people where searching for and what they where actually booking; that data was used to allocate/withdraw resources from busy/lame flights, and part of this was done by hooking up GA to their backend system
Take a look at the GA Partner Page. I would say the primary reason is to "liberate" GA Data from outside of GA itself. As Eike mentions, you can create dashboards and combine this data with other sources for a complete "View" of your online presence.
HI I guess there is no definite answer. Here are some things you can do with the APIs:
Automating AdWords CRO based on keyword ad and campaign performance.
Scoring leads based on Analytics data (Engagement with different items) and external data from a CRM.
Collecting unsampled data using multiple daily queries
Filtering using several dimension.
Tracking conversions for periods longer than supported by AdWords.
Looking at a funnel via segments
Analyzing funnels with non-linear structures
Create more robust alerts
Export data to BigQuery and analyse it together with data from other systems.
Create Machine learning apps for behavioural customizing your site.
Create a dashboard with data from multiple views
Use product recommendation to implements "better together" in an online store.
Automate creation of accounts and properties + their integration in a Hosting provider's console.
Cheers!!
I have a requirement where I need to develop a web application in which two application users negotiate with each and later after agreeing on terms they are to trade illiquid bonds via Bloomberg. For this I need to generate the BXT and SXT Trade Tickets through my application. The question really is that is this even possible without the Terminal?
A white paper on Bloomberg API's website says
Other applications are possible, for example submissions of trade orders
But I am not able to find any reference or example how this can be achieved using Bloomberg API or any other service provided by Bloomberg.
I'd be surprised if you are able to do this, by definition a web application is hosted on server x and interacted with from device y. Bloomberg's entire business model is based around having a Bloomberg terminal on device y.
I'd recommend you look at other bond trading platforms not just Bloomberg, e.g. TradeWeb, MarketAxess or even the large brokers e.g. ICAP, Tullett who may have a more suitable API.
This might come a little bit late but you might want to have a look into Bloomberg's FIX API. I am working on a similar project and I have implemented this functionality in a web application that creates and sends Trade Tickets via FIX. You do not have to have a Bloomberg terminal installed. Your FIX session will connect directly to a Bloomberg FIX endpoint.
Bloomberg has a test environment for this. You have to contact one of their representatives and ask for a Beta FIX Session.
FIX is a publicly available protocol for exchanging financial information. A good starting point would be https://en.wikipedia.org/wiki/Financial_Information_eXchange
I'm a student working on a project related to SEO; I need to write an optimization tool, so I'm writing an application using C# and Windows Forms. The main part of the application is for keyword selection, and I want to use the Google AdWords API to obtain a list of keywords.
I downloaded the C# client library, but can't understand how to set up the project: I am getting the error:
"An API exception has occurred. See ApiExecption and InnerException fields for more details".
Maybe I have made a mistake when I edited the App.config file as I haven't changed anything else. Can anyone advise me where I should begin? I would be grateful to hear your ideas.
Unfortunatley, the AdWords API isn't as open as you might think: It's meant for ad agencies managing large accounts, or software vendors who want to build ad management platforms. You need to apply to Google for an API key to gain access; they used to give them out to nearly anyone with an account, and it took about 14 days to process the application. However, Google has got very strict about their terms and conditions over the past 12 months, and to put it simply, you probably won't meet them if you're building an SEO tool; even if you apply to build a full platform, you'll need to wait six to ten weeks for approval as they've got a huge backlog of applications to process at the moment.
As this is just a student project, you should actually be able to get away with just using the AdWords API sandbox, which is open to anyone with a Google account. This won't give you real keywords or stats, but would demonstrate your understanding of the platform.
Another option would be to check out the Ad Intelligence Service of the adCenter API; you'd still need to open an adCenter account (with a $5 activation fee), but you should be able to get an adCenter API key without waiting too long. The stats available from Microsoft won't be as extensive as what Google has to offer, but will still be relevant to the at least the US market. Also, being Microsoft, they've got a good range of C# examples.
You could use the sandbox, but it is good only for testing purposes. You won't get real values for traffic estimation and keyword ideas.
To use the sandbox, what you need is a Google account (your gmail account for instance). To initialize the sandbox,
In your App.config, put email/password/developerToken as your email / your password / youremail++USD (e.g. john.doe#gmail.com++USD)
Run the GetCampaigns.cs code example. It is under v201109/BasicOperations folder in the C# examples project. This will initialize the sandbox.
Run the GetAccountHierarchy.cs code example. It is under v201109/AccountManagement folder. This will give you 5 client emails and their customer ids.
Use one of these customerIds in the ClientCustomerId field of App.config.
Run any other code example.
The video is a bit outdated, due to recent changes in AdWords API, I need to update it.
you can find a very good article series about adwords api there: Google Adwords API
it is not that hard to learn how to use it! I think the API itself is very good documented and there is a good suppo from google.
Bloomberg Open API announced recently - is it just the Bloomberg SDK which had been (limitedly) exposed to public for quite a while?
My understanding is that Bloomberg SDK is possible to use only on the machine with a Bloomberg Terminal installed, but the recently announced Open API (which is syntactically the same) will be possible to use from any machine.
Is that correct? Are there any restrictions on the new API (say, delayed responses etc)? Just cannot believe they're giving away for free something that costed money - any clarifications are welcome!
EDIT: The above was probably not clear, so to rephrase:
I wonder if the newly announced Open API is syntactically the Bloomberg SDK API (or how they call it?) which has been available for years already
assuming there are restrictions on using Open API on any machine (comparing to using SDK from a machine with Bloomberg Terminal installed) - I wonder if those restrictions are specified in detail in some official Bloomberg doc.
I can myself guess on both questions, but I thought I'd rather ask :)
Since the data is not free, you can use this Bloomberg API Emulator (disclaimer: it's my project) to learn how to send requests and make subscriptions. This emulator looks and acts just like the real Bloomberg API, although it doesn't return real data. In my time developing applications that use the Bloomberg API, I rarely care about the actual data that I'm handling; I care about how to retrieve data.
If you want to learn how to use the Bloomberg API give it a try. If you want to test out your code without an account, use this. A Bloomberg account costs about $2,000 a month, so you can save a lot with this project.
The emulator now supports Java and C++ in addition to C#.
C#, C++, and Java:
Intraday Tick Requests
Intraday Bar Requests
Reference Data Requests
Historical Data Requests
Market Data Subscriptions
Edit: Updated Project link, moved to github
The API's will provide full access to LIVE data, and developers can thus provide applications and develop against the API without paying licencing fees. Consumers will pay for any data received from the apps provided by third party developers, and so BB will grow their audience and revenue in that way.
NOTE: Bloomberg is offering this programming interface (BLPAPI) under a free-use license. This license does not include nor provide access to any Bloomberg data or content.
Source: http://www.openbloomberg.com/open-api/
This API has been available for a long time and enables to get access to market data (including live) if you are running a Bloomberg Terminal or have access to a Bloomberg Server, which is chargeable.
The only difference is that the API (not its code) has been open sourced, so it can now be used as a dependency in an open source project for example, without any copyrights issues, which was not the case before.
I don't think so. The API's will provide access to delayed quotes, there is no way that real time data or tick data, will be provided for free.