I've been working in a Java-based version of Elastix Call Center Protocol for something around 6 months and I need some help.
Everything I found on the Internet was implemented in PHP and, in the most of case, very poor examples.
I even found an implementation in Java in SourceForge but it seems to be abandoned for 10 years.
My points are:
In my app I have to write campaigns and queues directly into Asterisk and Elastix database; there isn't an Eccp operation to do that, according to Eccp Docs.
I wasn't able to create a campaign through Eccp protocol either, because it seems that Eccp doesn't support that kind of operation.
And many other issues. I'm trying to work around these problems mixing Java Code to http calls to Elastix server in order to get these operations done.
Has anybody already worked with Elastix Call Center Protocol in Java? If so, could you give some directions, 'cause everything I've been doing ends up looking like an terrible workaround.
Any kind of help will be appreciated.
Open source Eccp2Java project (beta):
https://github.com/xbrain-dev/eccp2java/tree/master/src/main/java/br/com/xbrain/eccp2java
Related
I am exploring options how to convert my existing java application which has Sprint framework to Azure Cloud server less "Logic App" and "Functions" concept
without re-writing.
As far as i can see, there is no accurate information in microsoft websites.
Can any one please suggest me on the road map, that, how i must lift and shift my java spring frame work to Azure Function?
I am aware of the fact that there will be little modifications that i might need to do, that is ok with me. But not a complete re-write into some other language.
Thanks !
Hard to say exactly but with the new Java support as long any package you are using can be resolved with Maven it should work in Functions. The potential bigger question is what can remain as-is. Likely each of your controller methods would become Azure Functions - the method signature would change but the code inside should remain largely the same (HttpTrigger with a request message to a route). The models should be able to stay untouched. If you had any orchestration or workflows that would become orchestrated by Logic Apps - but since Logic Apps has no-code, it would mean re-creating that workflow/orchestration in Logic Apps.
Java is still in preview so you may hit some snags here and there, but let us know if you have any other questions along the way.
I have been working on an algorithm ( Not mine, I am just modifying it ) that predicts when to buy and sell on the FOREX market. I need to be able to open and close orders, dynamically update parameters of the orders ( such as stoploss, maximum stop etc. ) and receive real time tick data.
I have been researching for well over a week, and have no success.
The closest I have gotten is using JavoNet and Mt4 Api
I managed to import the DLL into java and use a MQL4 function, which was AccountBalance(), however this has returned 0.0, which was not the account balance, I messed around with the code and the settings on MT4 client but still no luck.
Q0: Can anyone please point me in the right direction?
I am new to automated FOREX trading but from what I understand there is a broker somewhere with a MT4 server and I connect to that server with my MT4 client on my windows machine.
Q1: If this is the case, do I need to make an API work with the server side instead of my client side?
All these DLL's I have tried so far have been used with the MT4 client software on my machine.
I have also been doing some reading on the FIX-Protocol and ZeroMQ.
Q2: Can these help me achieve my goal in any way (instead of creating some bridges between JAVA and MT4 DLL's)?
A0: yes, forget straight about REST and synchronous, blocking chains in FX-trading domain
A1: well, not a typical way. MetaTrader Server is a proprietary suite of systems on the Broker-side and theirs API are not disclosed to allow some 3rd party integrations against.
A2: FIX-Protocol is the industry standard LP-interfacing lingua franca. In case you have contracted relations with your institutional trading provider, incl. the FIX-Protocol GWY-port, this may provide you an A-level access to the Market and to integrate your trading tools against. If this is the case, forget about MT4 instrumentation, as prime-time cadences are far beyond the MT4 Terminal localhost processing architecture ( multiple events with a sub-millisecond TimeDOMAIN resolution are common, whereas MQL4 does not provide any direct support for multithreaded-concurrent / better parallel programme scheduling designs ). FIX-Protocol events are simply off-the picture above, being far left, "before" the graph starts from 1st [ms] column.
ZeroMQ may help liberate your further designs from MQL4 limitations. May like to read my other posts on distributed systems, where MQL4 / ZeroMQ / ML-AI-predictors / GPU-processing infrastructures appear.
Anyway:
Enjoy the Wild Worlds of MQL4/MQL5
Interested? May also like reading other MQL4, ZeroMQ distributed processing and low-latency trading posts
You can try MetaApi https://metaapi.cloud cloud service which provides REST API and WebSocket API access to both MetaTrader 4 and MetaTrader 5 accounts.
Official REST API documentation: https://metaapi.cloud/docs/client
SDKs: https://metaapi.cloud/sdks (javascript, python and Java SDKs are provided as per April 2021)
It supports reading account information, positions, orders, trade history, receiving quotes, and accessing market data.
The service also provides copy trading API https://metaapi.cloud/docs/copyfactory and API to calculate forex trading metrics on a MetaTrader account https://metaapi.cloud/docs/metastats.
I started to code an expert with MQL5, naturally on MT5 platform, and I must admit that the difficulty of managing the application along with the increase of its complexity is high. It's not only due to a missing garbage collector, that of course imposes the deletion of the new instances, but also because Java offers a set of powerful data structures and syntax that MQL5 naturally doesn't have. Last but not least, talking about the community and the third party libraries available, there's a light year of the distance between Java and MQL5. I.e. if I need to find a library for a JSON conversion on the Java side I find dozens of official and stable versions, in the MQL5 community I have found only rubbish that I had to modify myself.
So, after numerous failed tries on coding my expert in MQL5 (not a simple one of course), I decided to adopt a radical approach: coding an application, client-side MQL5, and server-side Java, that provides a Java facade for the MT5 platform. Same API, same basic events and so on. Even though I thought more than once that I was getting stuck in a blind path, I kept coding and eventually, I made it, obtaining a really solid result.
Naturally, the REST interface drastically reduces the performances, and each request, even with Tomcat and MT5 running in the same localhost, is in the order of milliseconds, not micros, but on the other side this reduces only the suitability of this architecture, it doesn't make it useless at all.
Strategies like scalpelling and every kind of high-frequency trading are not good for such kind of scenario, vice-versa every other strategy in the longer period, even if intraday's ones, can be implemented successfully without any cons.
Last but not least, it isn't necessary to use the WebRequest() MQL5 method to call any Servlet container, it is possible to import the wininet.dll from the OS (talking about Windows) and the strategy tester will work as if the strategy has been coded in MQL5, maybe just a little bit slower.
To sum up, I wouldn't be so sarcastic on the Java facade approach for the FX trading platforms, citing only the nude performances without contextualizing the overall scenario is a naive approach to face the argument.
If you need to send/receive synchronous message between MT4 and Java application, REST would be the best approach because fast response matters in this scenario. Message Queue solutions like ZeroMQ fits better in asynchronous solutions, so it won't help you. Once you choose REST approach, you can use MQL4 WebRequest() to call your Java application.
WebRequest isn't the end of the world, you can submit http requests from your EA using API, works even with Strategy Tester.
In order to collect the tick information and open, update or close orders, you can use mt4 server api.
please check this url.
http://mtapi.online/#overlappable-4
Maybe you will find what you want.
And then I have also mt4 server api. If you have any questions please update me.
This wiki page, http://wiki.apache.org/couchdb/Getting_started_with_Java, lists several CouchDB Java clients. I wonder if any of the clients mentioned is significantly more dominant/popular/better/supported than the others.
I think Ektorp is pretty much the clear leader at the mo. I've certainly been very happy with it, and I've never seen anybody using anything else.
In addition, as a quick metric, Ektorp is clearly far more actively maintained than any of the others: currently the last commit on Ektorp was 5 hours ago, vs 4 years for CouchDB4j, a little over 1 year for jcouchdb and 2 years for jRelax.
I tried CouchDB4j and it has only a few methods implemented. They are not so well documented and you might find the complete lack of code example implementations very frustrating as it happened to me.That is why I would not recommend it. To give you a feel about this API, I tried attaching a certain file to an already existing document from the database and it does not support this kind of process.
I will now give Ektorp a shot and will come back with an edit as I go along. Looking at the recent activity between these two it is a big difference: Ektorp has been last updated a month ago vs CouchDB4j having been updated 3 years ago at the moment when this comment was written. Hope this will help.
EDIT: Ektorp is definitely the way to go. It allows you to build your own kind of entry in the database, with as many and variate fields as you want. It also allows easy manipulation of attachments. For me, it did the trick.
Lightcouch seems to be most active nowadays. Ektorp is also still active, however.
Each has its own strengths, however, so I'd pick based on what level you want to be abstracted from CouchDB's HTTP API. Myself, I'd use Lightcouch.
Nowdays the most well supported Java Client for CouchDB should be the official one from IBM cloudant-java-sdk as it is their interest to maintain it. Here you can find it on Maven Repository.
In order to work with AD's Global Catalog from a Java program , I am required to perform a CLDap (Connectionless ldap) call from my Java program.
I am looking for some open source to perform this task, but in vain.
Has someone experienced creating CLDAP connection in Java and can help around?
Many thanks
Zaske
Surprising requirement. CLDAP was moved to 'historic status' in 2003, see RFC 3352. Based on that, (a) I doubt you will ever see a Java API for it, and (b) I would just use LDAP over TCP: it will work at least as well. See also here where its removal from OpenLDAP is discussed.
Does anyone have links and resources to connect to an AS400 from Java?
I remember years ago, somebody told me about a connector that simulates KeyStrokes from the keyboard and other "purest" approach that connected directly.
On the web I have found a lot of links, but I cannot find a complete product to do this (I am probably not using the right keywords).
EDIT
Thanks for the answers:
What we are looking for is a way to access the data inside the AS400 and/or the screens it uses and expose them for other new applications re-use. Either as a webservice of some sort, or directly through Java ( and java will expose the operations using webservices )
Thanks in advance.
EDIT
As per MicSim post, I've also found this link:
http://www.ibm.com/developerworks/library/ws-as400/index.html
What you are looking for is probably the Toolbox for Java™ & JTOpen from IBM. There is also an AS400 class in the toolbox for performing specific AS400 tasks. You can look here and here for more details. Just googled it and hope it's helpful.
IBM's 5250 screen-scraping technology was "WebFacing" - I would post a link but you're probably better off Googling it, since IBM's documentation is so scattered. There are other technologies available too but: Screen-scraping was never anyone's favourite since typically you end up with something which, although it looks more up-to-date, actually is harder to use than a green screen and no more functional. The 5250 is probably the single best data entry platform I've ever used - web forms in a browser are one of the worst.
As mentioned, jt400 is the way to go for most other things. In particular:
JDBC - for all things SQL. If you do it right and address your files as though they really are tables, it's a way to get away from the 400 entirely.
Record-level access - write Java programs using a similar database API to RPGLE (all those chains, setlls that 400 programmers love)
Call programs, system commands, manage resources (data queues, data areas, prints / spools, jobs etc etc)
Good luck
If you just want to run Java on the AS/400 (or iSeries, or System i, or whatever IBM's marketing department has decided to call it this month), that's a supported language. You can access the pseudo-DB2 database directly. Or are you after some other form of integration?
This obviously depends on what you want to do, however if you want to simulate keystrokes across a network connection to an AS400 process then Expect4j may be the library you are looking for.
This is generally a really nasty hack though and there are frequently better ways to achieve your goals. What are you trying to do?
The expect4J library can be found here. Expect was originally a unix command that allowed you to specify a string that you are expecting to see and then a string of characters to return. It was frequently used for automating logins etc and for screen-scraping applications.
Even better is the TN5250j Console, which can be used to extract data from the AS/400.
jacada makes tools to do what your looking for
http://www.jacada.com/