Dissecting the Nest Plus Auto Trading API

3. A dry run

A quick-and-dirty trial will put some of the API functions in perspective. Unfortunately, there is no trading equivalent of a "Hello world", is there? While a GetPlusVersion would have been a no-risk illustration, that has issues. And there is no simulation server that can be used for testing. Limit orders on Hindalco with quantity as 1, using an AmiBroker afl, should do.


UserID has to be replaced with the trading ID, for example if the ID is BL155 and broker is Zerodha, the UserID would be BL155-13906.

Note: In this example, the first order should be rejected as it uses NRML.

3. A dry run ... [2]

The first two commands (CreateObject and SetObjectName) are just plumbing. The latter two, using PlaceOrder, do the grunt work. Of course, in practice, placing of orders would be the end-result of whatever are your buy/sell conditions -- you would not be using hard-coded values like this.

[[ Have not seen the GDFL AFL for some months now, but if a recent version uses more than these three commands to access the Plus API, please let me know. ]]

When using this test AFL, you do not need to attach it to any graph, etc. If working with the Formula Editor in Ami, simply click the Verify Syntax icon to execute.

This trial uses NOW and assumes that you are subscribed to the Plus Trading Plugin. If everything is okay, you would see a window popup similar to :




This window applies to the retail trader, where manual confirmation of order is required. Once an order is placed, a Refresh would show you the Nest Order Number in that column. This window takes up a lot of screen real estate; probably multi-monitor setups are required.

This is where concept of slippage plays role. In almost all automated software, It is always advised to send in a Limit order at price P with slippage s. In case of Buy, it will effectively be Limit Order at P + s. In case of Sell, it will be P - s.

Re: 2. Exposed COM/OLE interfaces ... [2]

I did not get you.... what are you driving it. Are you trying to convey "Buy combined with Sell" can only decide profit, or something else.

Re: 3. A dry run ... [2]

I See! Sharekhan manages it differently. Each time an Order is place, a dialog box that occupies entire screen with OK button at bottom. Most of it is empty. Once Order is placed, it is visible in Net Positions and Order Book of TT itself. I get Order ID back in my application and have to actually use it to keep track of the Order.

Most respectfully, I disagree.

4. CreateObject

In Ami, CreateObject is used to, well, create an object to which you want to connect via COM / OLE. Ami coders are familiar with CreateObject("Broker.Application") to access AmiBroker. There is a small difference in that the first is to an object within Now/Nest and will fail if Now/Nest is not running, while the second is to the AmiBroker application itself and will cause the application to start if not running. The object creation is not part of the Plus API but handled by Windows.

The "nest.plusapi" part is the identifier of the specific object to create. Is it "Nest.PlusApi" or "NEST.PlusAPI" as different samples use it? Doesn't matter. But, if a stickler for the christened name, look up the registry for the VersionIndependentProgID -- its "Nest.Plusapi". (Screenshot)

Besides AFLs, most languages support COM/OLE and could be used to write the dry-run code: vbscript, C, .Net, python, php, or whatever is your favourite poison.

Like most client-server applications, there could be more than one such client object. You could have GoldPetal and GoldM in one Excel sheet, and CrudeOil in another Excel sheet, each operating the RTD interface independently. Similarly, one could create multiple plusapi objects, each running a different strategy. However, most examples tend to create a single object with
The key difference from the user perspective is that using a static object results in one Api Generated Orders screen. All orders, using the same static object, show in the same window. If you are using multiple plusapi objects, each will have a separate Generated Orders window.

Notice that the Generated Orders window does not have a minimize / restore icon (!!). If by mistake or intent you close this screen(s), there is no obvious way to bring it up again. Howevever, a fresh order from the same object tied to this window will redisplay it, including the list of previous orders. If you lose the object, either by terminating the AFL in the case of non-static objects, or by closing AmiBroker in case of a static object, all connection with the corresponding Generated Orders screen is lost.

Just for completeness, there is no such thing as DestroyObject(); if required, set the object to Null.

Re: 2. Exposed COM/OLE interfaces ... [2]

Sorry ... I get you now. You were referring to word automatically before the TP and SL in my post. Weren't you?

Currently, my system does actually does fire a TP or SL order "automatically".
It is in quotes as I mean to imply that it is done "without any manual intervention". About the most crucial thing that triggers the Reversal order is the Price. The system is designed to send reversal Order once a particular price point is reached.

Of course, this portion of s/w (to check whether price reached TP or SL) does not execute until it has received 100% confirmation that the parent order (the Order that is meant to be reversed) was Fully Executed.

Both Sell and Buy Orders need to be fully executed to confirm whether strategy made Profit or made loss.

4. CreateObject ... [2]

Multi-threaded AmiBroker (version 5.4 and later?) cribs strongly when OLE is used. For the CreateObject line, it will say:

Warning 503. Using OLE / CreateObject / CreateStaticObject is not multi-threading friendly. See User's Guide "Efficient use of multithreading' for more details.

If interested, full version of warning 503.

I am unsure how strongly to take this warning in practice. An OLE call, while slow, would be a few milli-seconds. This may be inconsequential to a retail trader that needs to manually confirm orders. Higher-frequency orders are not something to jump into, and has bigger latencies to think about.

Even so, ran a test. Got Ami using between 70 to 80% of CPU by opening 4 different symbol charts using different AFLs that were heavy, had sub-second quote updates. There was Odin, NOW and 3 other programs running on a 5 year old machine with 1 GB RAM. A test run from an external app of 1000 iterations fetching the database name via OLE took 16981 millisecond. So the outside case is below 17 milliseconds per call for that situation.

Unanswered question: If both Now and Nest is running on the same machine, both with autotrading enabled, how does one selectively access one or the other (assuming late-binding) ?

Re: 3. A dry run ... [2]

Are you saying it is a blocking call? Cannot imagine that it would be designed not to be asynchronous.

Or do you use a separate call to get the Order ID? Is it Sharekhan's internal order ID or the exchange ID?