My company has an outsourcing partner that hosts data on a z series mainframe. Data is not in db2 but in some older structures. I guess vsam tables, if I haven't misunderstood those mainframe guys. We don't have ih-house knowledge of the mainframe technology. When we talk to partner's mainframe guys it sounds like they speak foreign language. We don't understand them, they don't understand us. PC world and mainframe world are quite different, yeah.
We access data through 3270 terminal emulator (IBM Persona Communications).
Teminal emulator does not connect directly to mainframe but rather to HIS 2000 Server (Microsoft Host Integration Server). HIS talks SNA to mainframe while clients talk tpc/ip to HIS server. We have an internaly developed helpdesk software (writen in c#) that monitors availability of other systems. Now we have request to extend the solution to monitor availability of the mainframe. The idea that we have is to start a 3270 session from our code. If connection suceeds system is available if not it's not available. We don't need to log in to mainframe and access any data there, just check if 3270 connection opens. I know this doesn't mean that actual data is available (sometimes data is locked by batch jobs and we can't access it even though system is up and running) but this approach is good enough for us. Could you point me to some documentation or existing projects? Can we use HIS or Personal Communications libraries. I haven't found any documentation on it.
Well, I finally got it.
I'm using Personal Communication api.
All functions exist in two dlls - pcsapi32.dll (pcsapi functions) and pcshll32.dll (ehllapi functions) that are part of Personal Communication installation.
Everything is well documented in IBM documentation that can be found on
http://publib.boulder.ibm.com/infocenter/pcomhelp/v5r9/index.jsp?topic=/com.ibm.pcomm.doc/books/html/emulator_programming07.htm
or downloaded as pdf.
I had to p/invoke native windows functions and had no problems with it. Tried to use host access code library automation objects but had some issues with it and gave up.
Found usable code example at codeproject site http://www.codeproject.com/KB/cs/all_ehllapi.aspx
I am not sure if the solution I have would work for you. I used IBM PC Communicator Emulator and connected it to MS Excel using the APIs available for it. You can have a look at the APIs coding documentation here - http://publib.boulder.ibm.com/infocenter/pcomhelp/v5r9/index.jsp?topic=/com.ibm.pcomm.doc/books/html/emulator_programming07.htm.
If you need sample code to connect to MF from Excel via 3270 Emulator please let me know, I can provide the same to you.
Regards,
Nitin
nsrivastava2 [at] gmail.com
Related
I am given a project where we want to develop a POS based web application using asp.net.
I have already looked at POS for net and its a wel-known fact that due framework changes, POS.net needs some config file setting changes. My target framework is 4.5, and so far I don't know how many more libraries are depreciated.
I tried to create some sample applications for Proof-of-concept, I tired ActiveX components, SL4/5 applications to read client machine's COM ports. Since its a development env, I even tried accessing webserver's COM ports.
These applications have their own drawbacks. I also want to mention that since the development is under controlled environment, security settings( for ActiveX) isn't a issue.
1) Using ActiveX restricts the client machines to Windows OS. There is an option to created browser plugins using NAPI, but I couldn't get further with it as it has its own learning curve and the programming is in pyton.
2) Silverlight OOB( out of browser) application seemed promising, but the sample from
codeplex didn't work in all scenarios
Am I missing out on something?
Please note I have already studied WSPOS implementation.
So far the applications which we have seen that can access client machine's COM ports download a JAR file. The team is finally at a stage where they are concluding that this can be done using JAVA and not C#/.net.
Please let me know what basic point I am missing.
How much control do you have over the client machine? You could write a Windows Service that your web server would interface with. You would just have to know what terminal your user is logged in from.
This has been asked a lot, but I'm after more specific answers.
I'm designing/developing a suite of applications that are dependent on communicating with a agent and a manager. They will be communicating commands (from manager to agent) and statistics (agent to manager). At the moment, this suite of applications will only run on the Windows platform, but eventually should scale out to other systems. Some places where this application would be used might not want to install a great load of applications across their systems, and some might not want the manager side sitting there sucking up juice (analysis!) and therefore might want it in the cloud.
So, I know that I can use .Net TCP sockets, which seems to have good raw performance and allows me a great deal of flexibility.
I also know that I could use Windows Communication Foundation, which seems like naturally a better choice.
But, seeing as I'm sending commands and receiving statistics, I could just use Powershell to connect remotely and use the plethora of commands available from what would be the server, ruling out writing a client application full stop.
Bearing in mind that these applications (client especially) should just sit there, be quiet, do their job and not interfere with general operations, which would you suggest to be better?
If you need more clarification I'll be happy to do so!
Thanks.
The way you discribe your application, I would reformulate it as an 'agent' located on clients and a manager located on the server. If it's so the manager sends commands to the agents and the agents respond or store statics available to the manager.
For such an architecture you can imagine using WMI, with a WMI provider on the agent, and wathever you want on the server. Powershell can be used on the server to query your agent. In the near future you can use the same architecture puting your agent on a Linux box with NanoWBEM on the top of WS-Man Protocol (see Standards-based Management in Windows Server “8”) .
They will be communicating commands (from server to client) and
statistics (client to server). At the moment, this suite of
applications will only run on the Windows platform, but eventually
should scale out to other systems.
In your description there is one requirement that is not compatible with Power Shell.
Power Shell works only in Windows world.
WCF service should not consume any resources if they are properly configured. IIS and WAS are able to load services on-demand (upon getting request from client) and unload when it is not necessary.
http://blogs.msdn.com/b/blambert/archive/2009/02/13/enable-iis.aspx
http://msdn.microsoft.com/en-us/library/ms731053.aspx
TCP sockets are the best from performance point of view but unfortunately implementation will require lots of extra DEV and QA work to implement all plumbing that already exists in WCF. When you finish that work you will have one more "bicycle" that is not compatible with industry standards.
My vote is WCF.
I need to find a solution or develop one for allowing employees to enter their "hours worked" at the end of the day and then easily and quickly "pushing" that data to Quickbooks Pro 2010.
I'm trying to formulate, in my mind, how to build this type of solution. With my understanding of QuickBooks integration I think it will look like the following:
Quickbooks Software on PC
|
|
Custom App "Linking" Online DataStore to QB (on same PC as above)
|
|
Online Data Store Such as MS SQL Server, MySQL, or CSV Files
|
|
Website or Web Service Used to Receive Data From Blackberry Phones
|
|
App on Blackberry Phone to Enter and "Push" Data To Data Store in the Cloud
Do you see any flaws in this design? Any ideas how to improve on it or simplify it?
Remember, the application on the PC will likely be on a consumer or small business network that doesn't even have static IP.
On a separate note, as near as I can tell nothing yet exists that will do what I'm looking for. The apps I have looked at require you to import iif files into your phone (specifically ReportAway). During an initial test of the app, the import failed to import anything but did not produce any error messages. It's unclear to me how the data gets input from the BlackBerry app to QuickBooks but it appears to simply be CSV files. If someone does know of an existing app for this I'd appreciate knowing about it. However, we may still opt to program our own anyway.
You're on the right track with what you proposed. I have a few further suggestions:
Instead of building a custom app that sits alongside QuickBooks, why not re-use something that's already built? For instance, the QuickBooks Web Connector or (if you're building a SaaS service) the Sync Manager via the Intuit Partner Platform? Both of those are specifically designed to enable web/remote applications to communicate with QuickBooks. There are C# examples of doing almost exactly what you're talking about included in the QuickBooks SDK, and open source QuickBooks libraries for doing what you're asking.
Why would you ever want to use CSV files for storing data? Do yourself a favor, and use a database.
You could easily make the phone end of things available via more than once interface- build a web interface for iPhones/web browsers, and an app for Blackberry if you want. Once you have the infrastructure, the actual interface/view should be trivial to implement.
Have you looked at the available Workplace.Intuit.com apps for time tracking yet?
are you wanting to build your own app? Your best option is the build your phone app that makes a call to a web service hosted somewhere on the network where QB is hosted, the service can use the QB API to put the data where you need it. Or simply create a website that they can browse to that will make the call to the API, then you dont even need to bother with a phone app.
Phone/Website > Web Service > QB/SQL
I have solved exactly this problem in the past, in a manner very similar to as described by DustinDavis. In my case, I simply connect the smartphone client app to the php app server. App server stores the data immediately. In a separate scheduled process, app server refreshes and pushes data to QuickBooks server every 15 minutes or every 30 minutes as configured. I can provide more details if you are interested.
I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.
You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.
Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.
If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.
You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages
You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.
Are there any good api's or examples of communicating between two devices via WiFi?
I am programming an app for 600 window's mobile (version 5) devices. They occasionally will need to connect with another device and exchange info.
Each device connects to the internet via GPRS (using the phone line). I could do the communications via that, but it is slow and may not work in all locations (this app will be used nationwide).
Just as an FYI, I also plan to look into bluetooth, but the stack we get on our Symbol Devices (MC70) is the Stonestreet One stack (we cannot change that). It is a very difficult to use stack with no managed code API. Also, it requires manual setup to use. My users will not be very technically inclined.
If there is another way to communicate (ie via the WiFi connection) I would love that.
(Ideally, I would like to be able to programmatically turn on the WiFi, send/receive data and then turn off the WiFi (to save batteries).)
Any help/suggestions are appreciated.
Motorola (who have bought Symbol a few years ago) do release an Enterprise Mobility Developer Kit for .NET CF which also has some libraries for controlling the WLAN on a Symbol MC70. I have worked with this in the past and it seems to work very well. The SDK comes with the full documentation and some sample applications.
Here is an earlier question on this subject:
better way to communicate between ad hoc wifi windows mobile devices
... which suggests that this is at least possible.
As an alternative, if the devices have infrared ports, you could have them communicate that way (I think).
Update: just found this example:
http://community.opennetcf.com/articles/cf/archive/2008/06/09/exchanging-data-using-windows-mobile-windows-communication-foundation-net-compact-framework-and-exchange-2007.aspx
It looks like you can do peer-to-peer communications with it. It requires .Net CF 3.5, however.
Someone is welcomed to prove me wrong but, as far as i know, out of the box it has to be bluetooth. WiFi is for networks. If you setup each device to also act as an access point you could make this happen. So I am sure it can be done, but it's not a clear path.
I see other issue slike security as well, because a router would handle this and now each of the 600 devices would be an access point handling this security, i am just shooting from the hip now which is basically my long winded advice to not go that direction.
-update
maybe i am a bad answerer, I just thought this was a bad direction. You can google windows mobile wifi peer to peer. Here is one site that covers it.
http://www.smartphonemag.com/cms/blogs/3/588