I need to connect clients (c#, winforms) appliction with Interactive Brokers and improve app with some "stock market" functionality.
First I start project with reading IB documents and learning IB's API.
After I did that I'm just more confused and didn't find anything useful!
I want to ask if someone knows where I can find documentation that would explain everything from the beginning, from creating test accounts, using IB's API, to connect to IB system...
If such documents doesn't exist can anyone give me answer the following questions:
Does my application using IB's API can directly connect to IB system or it must use TWS (Trader Workstation)?
What is the purpose of IB's API when TWS must be running in the background?
Is it possible to create a test account on IB?
I would be grateful for any advice, a link to the documents or examples. Thanks in advance.
There are two options to use IB API. You can connect either to TWS application or to Gateway application (same as TWS but without user interface). Gateway is specifically designed for API use so you do not have to run full TWS on the background.
Interactive brokers does support paper trading account. It is just like your real account with full functionality but fake money so you can test your API or system.
Here is very simple example of how to send an order through API:
http://www.bowgett.com/Blog/post/how-to-send-an-order-to-ib-tws-in-just-68-lines
As others mentioned, your C#/C++/Python/Java/VB/etc. program incorporates the IB API code libraries. This program then connects to either the IB Gateway or Trader Workstation (TWS). So yes you need to keep ether the IB Gateway or TWS running and connected to the IB data center all of the time your program is running.
You can create a paper trading account with IB to do testing. You can also use the "edemo" account to test basic API functionality and connectivity. However the edemo account only sends back some canned data to most market data requests. You can do a lot with edemo as far as testing goes but to see anything "real" you would need to open a paper trading account (and eventually a funded account).
In addition to the tips others suggested, you might find some introductory tutorials useful. For example: http://holowczak.com/ib-api-tutorials-by-programming-language/ has tutorials on IB API using a variety of different languages and Windows / Console alternatives. In these tutorials, the interaction between your program, TWS/IB Gateway and the data center are discussed. Also discussed are the API architecture and the publish/subscribe messaging model that IB (and many other market data APIs) uses.
Related
I have WPF program as a Kiosk application using Lync sdk to make 2-way video call. I want to make similar application but using Microsoft team. The step is as below:
kiosk app calls recipient -> recipient accepts call and sees video streaming from a person standing in front of kiosk app.
kiosk also gets video streaming sent back from recipient and shows that on app interface.
users at kiosk side will only see custom interface we develop, not Lync/Microsoft Teams UI.
As far as I understand for Teams, native app (kiosk) needs to call bot api and bot will call MS Graph via REST and Graph will create a call to recipient. I don't quite understand how to proceed after that:
How caller (kiosk) can receive video streaming from recipient?
How caller (kiosk) side turn on camera programmatically?
In Lync, we will install Lync libraries and Lync client on application side, then Lync will handle this itself, so the app using Lync will create a call directly to callee.
In Teams, it's different as the app needs to call Graph to create a call. So I am really confused how to do this.
The Lync Client SDK remote controls the Lync Client. There is no such SDK for the teams app (the teams app is basically just a web browser, going to the teams web site is basically the same app minus the audio\video support).
So there is no way to do a UI-Suppression mode.
What you can to is control the teams app using the Windows Automation Api. Using this API you can remote control the teams app to do what you want.
There is a bunch of applications written using this API for you to try manually like the Microsoft Testing Tools or Automation Sky. Once you have found how to do what you want using these tools then you need to convert your manual usage of these tools over into code to remote control the Microsoft Teams application.
I know it generally works as we have remote control the teams applications here. The problems you will find is that the Teams application is really just a "special" web browser to display the Teams web site. This means it can and does change A LOT. So you remote controlling of the Teams application may break at any time. So you may to program your solution to be as dynamic as possible so that you can update how you control the Teams application either live or as quickly as you can.
The current project I'm working on is a Windows Form Application, which in large part functions as a background service to make Queries to a decent number of APIs and store that information into a database. Pretty straightforward.
As I implement more data sources the issue I'm running into is that one of the places I'm pulling from wants to use webhooks to push that data to me. Again fairly straightforward, I did some tutorials on making ASP.NET Web API projects and all of that makes sense in isolation.
Now what I'm confused about is to tie it all together. From my understanding, the options I have would be to have the Form application and the Web API application run separately, which seems like more separation than I want (especially considering that the webhook is for a single item of data that already ties into what the Form application is handling). Alternatively the other option would be to get the Form application to to self host a Web service which seems like the way to go, but I'm unsure of how to approach that without starting with the Web API shell.
I tried reading up on it and this and this seem to solidify that it would definitely be possible to just host the webhook receiver/controller server inside of the form application without making a new project for it. But I'm not sure of what config, new files and settings of that kind it would take.
I would be super thankful for anyone who could offer guidance about how to go about implementing this webhook controller in a project type not designed for it by default, or if you could tell me that it's a bad idea and I should make separate projects for them.
Thank you for your help!
"Webhooks" (or HTTP callbacks, in general) require a publicly routable address. At home, your desktop computer likely sits behind a NAT and with a dynamic IP address, so it won't work unless you enable port-forwarding and find out your publicly routeable address (assuming it's possible at all and you aren't running inside a restricted company or school/university network). You'll probably want to use AWS Lambda or Azure Functions as a quick and simple way of accepting messages from the public web which your desktop program can retrieve them from later-on (using a "mailbox" paradigm). You could try making it work in real-time with a WebSocket or EventSource but I don't know if that works from AWS Lambda or Azure Functions - if it doesn't then you'll need a "real" website.
All systems are Windows 7, programming will be done in C#, targeting .NET 4.5.2.
The goal is to have a core program (I hesitate to refer to it as a service because I don't want to muddy the waters) that runs regardless of what user is logged in to the PC. The core program will run all the time. Users will log in (at least to the client program by authenticating against an internal system, if not the PC using Active Directory) and client programs will send and receive data to and from the core program. Since these PCs are in common areas of a secure facility, they currently auto-log-in as a generic user. This may or may not change, but the program requirements dictate that they will at least have to log into the client program.
What is the best solution for this scenario?
I had thought this would involve a Windows service and named pipes, but I haven't found a working solution yet. I have tried several WCF named pipe examples that work wonderfully if both the client and server are in the same user session, but have not found the key to getting them to work across user session boundaries. Now I'm wondering if I should take advantage of the fact that a generic user is logged in automatically and have the core program run as that user.
This is my first SO question, so Hello World!
[Edit]
The 'core' and 'client' programs will reside on the same PC, there is no need to communicate with the network. The core will retrieve data from a database and pass data on to a piece of industrial equipment. The core would also need to receive data from the industrial equipment and communicate that data to any clients that are listening, if any. It also logs that that data on the PC. The client program will display the data from the industrial equipment as a chart. I'm trying to be as clear as I can, but I don't know which pieces are important.
I'm facing a use case, where it shall be possible to take over a Lync/Skype for Business Conversation into my Software. The help desk user was contacted by a customer via Skype for Business and now needs to create a ticket from that conversation. Only the chat-conversation is needed, no voip conversations or so.
I could not find any documentation about how to start any Actions out of a Skype for Business conversation window.
I'm sure, somebody solved that before.
Note that:
- "Skype for Business" is basically a rebranded Lync, so Shane's advice about the "Lync Client SDK" is correct.
- "Skype" != "Skype for Business". It's like java and javascript, totally different, just similar names for branding.
- Persistent Chat means "chat rooms that remain". Skype for Business has regular IM chat and its much less used "Persistent Chat".
- tel.red can do this for you if you pay them.
I think what you want is to use the Lync Client SDK specifically the parts dealing with Persistent Chat, there are samples you can play with.
If you don't want to integrate into the Lync Client itself, you can go down the UCMA route and create a "bot" that can take part in chat conversations.
Using Skype's own API is probably the best way.
http://www.skype.com/en/developer/
I am not able to get the lync sdk controls to work when Skype for business/lync is running using app-v. it works fine when the program is "installed" though.
when running Skype for business/lync in app-v, the error is basically lync client not found, even though it is obviously running.
I've been developing an application that interfaces with PowerShell for Windows. So far, everything has worked great. However, it connects to MySQL directly (I guess that's not good practice?) and also connects directly to the local PowerShell instance. My goal for the future, however is to make it cross platform. I currently purchased a book on cross platform development (mono based I believe) to get a handle on have a best practice common services layer for some basic things. However, I can't get my head around how I'll do that with PowerShell.
My question is, is there a way to host a server somewhere that accepts Powershell connections remotely via web requests from multiple connections at once? Otherwise, I don't see how I can port such an application to Android and the likes.
Also, I wouldn't be opposed to some basic links for best practices on web requests and the likes.
Have a look at PowerShell Web Access.