I'm trying to automate in an AS400 terminal using UiPath.
I experience stability problems where the screen "blinks", which can cause errors. This outputs a trace log: "XMLScreen:Render BUGBUG XMLScreen.Field is blank".
I am connecting with UiPath internal and wondering if that might be the cause of my problem. I've searched for hours, but cant find any information on what the difference is between UiPath internal and IBM EHLLAPI. The only difference I know is that EHLLAPI uses an already existing terminal session.
Is one way of connecting generally a better choice than the other regarding stability and why?
All inputs are greatly appreciated! :)
The two options work completely differently.
EHLLAPI works against existing installed IBM i Access for Windows or IBM i Access Client Solutions (ACS) software. It is a very specific, solid, and well established IBM proprietary API that does not use Telnet in any way. You would need to ensure that EHLLAPI support was enabled (e.g. http://www-01.ibm.com/support/docview.wss?uid=nas8N1010639 for ACS).
Your organisation may perhaps be using a third party emulator, e.g. Rumba - I think EHLLAPI is supported by some of these.
The UIPath internal option starts and writes to a TN5250 session, over which it sounds from the documentation as if you have little control (e.g. re keyboard mappings).
I would suggest you go with EHLLAPI if you can (i.e. if you have a suitable IBM or third party product installed as above).
But, are you absolutely certain you need to screen scrape this at all? Do you have no access to the IBM i source code, which would potentially allow you to write a suitable program to run natively? I feel honour bound to say this, because there is always grief with screen scraping IBM i applications (e.g. panels appear that you are not expecting, especially at sign on time, or if an error occurs).
I've been having a very confusing discussion with a colleague about the use of Network Direct in Windows to provide RDMA, and Linux where we have a working implementation using the verbs api and rdmacm.
Said collegue developed his Network Direct implementation after he couldn't get the verbs one to work. I did the rdmacm implementation under Linux. We both got them talking linux=>linux and windows=>windows but never got around to testing Linux=>windows or windows=>linux. During the development there was some hint of it possibly working, they appeared to start talking but of course things were still in development.
The project was put on hold for months and the framework that it was built into has had significant redesign. I'm left with pulling what was working from the Windows side into the new framework and I'm having a hard time getting it working or seeing any part of it connect from Linux.
My understanding is that at the lower layer they will both talk verbs. But I'm now not so sure with colleague saying things like "Remember this is not verbs", just to add to the confusion.
So the question is. will an application that uses rdmacm be able to establish a connection to an app that uses Windows NetworkDirect interface or are the two completely different and incompatible?
According to Mellanox support, Network Direct should be compatible with InfiniBand verbs. We've had good luck doing RDMA transfers using rdmacm Linux-Linux and Windows-Linux. We used the windows libraries available at open fabrics alliance (look for ofed_sdk). It was not easy to figure out what libraries to get in order to do the Windows part.
However, Microsoft does not want people to use the ibverbs approach on MS-Windows any more. If you are having trouble getting ND on Windows to talk to Linux, are you sure that you are putting the values in network order before shipping them over?
I need to write an SNMP agent on Windows for our company product.
SnmpApi.lib - It's my understanding that SnmpApi.lib allows you to create a full agent from scratch and probably requires more work. This, however, takes over the SNMP port and doesn't allow other agents to run and will take longer to code.
MgmtAPI.lib - This lib will allow one to create an extension to the already running Windows SNMP service and seems a more elegant approach to creating an Windows agent. However, I'm findining very little official MS documentation/examples on how to code such an agent. I've also read on another forum that this might be deprecated.
I've seen an Oreilly book out in the wild called "Windows NT SNMP" but I heard it uses deprecated libs or techniques. I don't know if this is true or not.
I've also seen libraries like SNMP++ that use the SnmpAPI.lib to create an agent, but again, this isn't as elegant as letting multiple sub-agents on the system via MgmtAPI.lib, it seems.
A few questions:
I heard that MgmtAPI.lib is legacy/deprecated. Is this true?
What's the best practice for creating a Windows SNMP agent?
What library should i be using?
Any other suggestions?
Thank you!
The default windows SNMP stack and framework is very limited in its ability. Unfortunately, your best solutions are probably found elsewhere (of which there are a number of external libraries and stacks). If you want one that is modular and allows sub-agents, then look into a stack that supports the AgentX protocol. That's a standardized SNMP subagent protocol and will let multiple sub-agents attach to a master agent.
But whatever you do, please pick a stack that supports SNMPv3 and use the security in it.
If you want a random stack example that is known to work well on windows, try Net-SNMP which is fairly popular among the "replace the SNMP stack on windows" crowd. But I'm also biased and associated with the project, so I'll end with saying: "it doesn't matter too much; pick any stack that supports both AgentX and SNMPv3".
I am developing socket reading on an ActiveX EXE (i.e on a seperate thread).
How many sockets i can safely read independently?
I am working on windows XP OS.
I think this might be an operating system limit - I think I remember running up against a limit of 80 sockets on the XP machine I was using several years ago.
I would recommend that you abandon your effort and go with a commercial solution. I remember going down this path back in the 90s and running into a brick wall with ActiveX EXEs as far as threading goes. The thing is that ActiveX EXEs are apartment threaded, not free-threaded, so you don't get completely independent threads.
And doing server side threads properly is hard enough in modern languages, let alone ones that weren't designed for this purpose.
I ended up purchasing Server Sockets from Dart. Easily the best investment for that project. The performance is truly great - you are only limited by the system resources.
MSWINSCK.OCX is a very old way of doing things; it came with Visual Basic 6.0 and i remember using it way back when. i'm not sure the licensing on it... apparently it registers fine under 32-bit win7, but not 64-bit; here's a link to how to get it to register on 64-bit systems: http://angrybyte.com/windows-hacks/mswinsck-ocx-for-64-bit-windows-7-vista/
if you have an MSDN subscription or similar that gives you the ability to download the developer tools (bizSpark, etc. will do it too) then i believe that will also give you a license to redistribute the .ocx.
(btw, i don't actually remember the interface, but i seem to remember it being at least slightly more intuitive than the berkeley socket() interfaces.)
however, personal recommendation given your requirements: learn the APIs, there are lots of examples out there, and just write yourself a class that encapsulates them in a similar way as, say, the .NET Socket class... the APIs aren't that hard and i'm sure there's lots of help to be had here as well, and that's probably better than relying on something that's out-of-date like the control...
I am trying to get started writing scalable, telecom-grade applications with Asterisk and Ruby. I had originally intended to use the Adhearsion framework for this, but it does not have the required maturity and its documentation is severely lacking. AsteriskRuby seems to be a good alternative, as it's well documented and appears to be written by Vonage.
Does anyone have experience deploying AGI-based IVR applications? What framework, if any, did you use? I'd even consider a non-Ruby one if it's justified. Thanks!
SipX is really the wrong answer. I've written some extremely complicated VoiceXML on SipX 3.10.2 and it's been all for naught since SipX 4 is dropping SipXVXML for an interface that requires IVRs to be compiled JARs. Top that off with Nortel filing bankruptcy, extremely poor documentation on the open-source version, poor compliance with VXML 2.0 (as of 3.10.2) and SIP standards (as of 3.10.2, does not trunk well with ITSPs). I will applaud it for a bangup job doing what it was designed to do, be a PBX. But as an IVR, if I had it to do all over again, I'd do something different. I don't know what for sure, but something different. I'm toying with Trixbox CE now and working on tying it into JVoiceXML or VoiceGlue.
Also, don't read that SipX wiki crap. It compares SipX 3.10 to AsteriskNOW 1 to Trixbox 1. Come on. It's like comparing Mac OS X to Win95! A more realistic comparison would be SipX 4 (due out 1Q 2009) to Asterisk 1.6 and Trixbox 2.6, which would show that they accomplish near identical results except in the arena of scalibility and high-availability; SipX wins at that. But, for maturity and stability, I'd advocate Asterisk.
Also, my real world performance results with SipXVXML:
Dell PowerEdge R200, Xeon Dual Core 3.2GHz, handles 17 calls before jitters.
HP DL380 G4, Dual Xeon HT 3.2 GHz, handles 30 calles before long pauses.
I'll post my findings when I finish evaluating VoiceGlue and JVoiceXML but I think I'm going to end up writing a custom PHP called from AGI since all the tools are native to Asterisk.
You should revisit Adhearsion as v0.8.1 is out, and the documentation has gotten much better quite recently. Have a look here:
http://adhearsion.com
http://docs.adhearsion.com
http://api.adhearsion.com
If you're looking for "telecom-grade" applications, you may want to look into SipXecs instead of asterisk. It's featureful, free, and open source, with commercial support available from Nortel. You can interact with it via a Web Services API in ruby (or any other language).
See the SipXecs wiki for more information. There's a comparison matrix on that site, comparing features with AsteriskNOW and TrixBox.
There really aren't any other frameworks out there. There's of course AGI bindings to every language, but as far as full-fledged frameworks for developing telephony applications, we're just not there yet. At least in the open-source world.
I have asked somewhat related questions here, here, and here. I'm using Microsoft's Speech Server, and I'm very intested to learn about any alternatives that are out there, especially open source ones. You might find some good info in the answers to one of those questions.
I used JAGIServer extensively, even though it's not under development anymore, and it's pretty good and easy to use. It's an interface for FastAGI, which I recommend you use instead of simple AGI.
The new version of this framework is OrderlyCalls which seems to have a lot more features but since I haven't needed them, I haven't tried it.
I guess it all depends on what you want to do with AGI; usually I have a somewhat complex dialplan to gather and validate all user input and then just use AGI to connect to a Java application which will read some variables, do some stuff with it (perform operations, queries, etc etc) and then sets some more variables on the AGI channel and disconnects. At this point, the dialplan continues depending on the result of the variables set by the Java app.
This works really fast because you have a ServerSocket on the Java app, which receives incoming connections from AGI, creates a JAGIClient with the new socket and a new instance of a JAGIProcessor (which you have to write, it's the object that will do all your processing), and then run the JAGIClient inside a thread pool.
Your JAGIProcessor implements the processCall method where it does all the work it needs, interacting with the JAGIClient passed as a parameter, to read and set variables or do whatever stuff the AGI interface allows you to.
So you have a Java app running all the time and it can be a simple J2SE app or an EE app on a container, doesn't matter; once it's running, it will process AGI requests really fast, since no new processes have to be started (in contrast to simple AGI which runs a program for every AGI call).
Smee again. After migrating my client's IVR's over from SipX to Asterisk utilizing PHPAGI, I must say that I haven't encountered any other architecture that anywhere near as simple and capable. I'll be stress testing Trixbox CE 2.8 today on the same hardware I had tested SipX on earlier. But I must say, using PHPAGI for the IVR and the Asterisk CLI for debugging has worked perfectly and allowed me to develop IVR's far faster than any other company out there. I'm working on implementing TTS and ASR today and I'll post my stress test results when I can.
Simple small flexible Asterisk AGI IVR written on PHP
http://freshmeat.net/projects/phpivr
For small and easy applications I use Asterisk::AGI in perl. There are also extensions for the Fast AGI. For bigger applications, like VoIP operator's backends I use something similar to OrderlyCalls written in Java (my own code). OrderlyCalls is great though to start with java fastagi engine and extend it to your needs.