Does UFT 12.02 supports ISO8583 & NDC protocol testing? If yes, can you advice the basic steps to configure the same in UFT.
The short answer is No.
They list Financial Services as one of the supported environments, but my experience that it is not financial transaction testing.
The longer version is while you can technically configure UFT to send these messages (if straight text) by capturing examples and sending them back through. Though when I was given a chance to use it as a trial and did this, it did not do it very effectively and had very high overhead compared other tools for financial transactional testing on the market than UFT. Especially for dynamic creation of data, packed vs. unpacked, BER TLV, encryption keys, or manipulation of data elements, and things that regularly change it is not very effective.
I would consider the following options, each of these vendor's have specific solutions for each interface and have many pre-built ISO-8583 modules you can license or you can create them on your own.
Paragon's FasTest
ACI ASSET
FIS's Clear-2-Pay (formerly Lexcel)
Paragon also has a product called ATMeMulator and ConfigBuilder for NCR & Diebold I have seen no equivalent product (or at least anything in the ballpark of features/functionality) out there for building and testing loads, screens, states, transactions, faults, etc.
Related
I would like to know some popular frameworks that are available for implementing CQRS, ES, Saga in the application.
As a part of my research, I have to compare these frameworks and evaluate them based on various -ilities.
I have to compare these [event-sourcing] frameworks and evaluate them based on various -ilities.
The premise of the question is that you need a framework to implement event sourcing but, in fact, you do not.
Greg Young, one of the most influential proponents of event sourcing, frequently expresses his misgivings about frameworks. See, for instance, his QCon London 2013 keynote, esp. mark 9'.
Event sourcing is conceptually simple and doesn't need the kind of magic that frameworks typically bring with them. For instance, rebuilding the state from a stream of events simply consists in a left fold over the stream in question. Moreover, you don't necessarily need a specialised database; I know people who have successfully implemented event sourcing by simply appending events to a file.
If your research aims at comparing event-sourcing frameworks, I would argue that you should consider the case where no framework is used at all.
Axon is a popular framework/server for building CQRS/ES applications.
EventStoreDB is a popular EventStore database for the EventSourcing part.
A simple starting point if you want to write your own framework/library is to check out some of the code I co-authored at https://www.cqrs.nu/
If you are looking for a managed solution, you can also check out what we at Serialized provide.
In addition to Axon, on the JVM there's also the Akka ecosystem (the cluster sharding, persistence, sharded daemon process, and projection modules are the most relevant to CQRS/ES/DDD). One benefit of Akka Persistence is the ability to choose from a variety of datastores to use as an event store (JDBC SQL databases and Cassandra are the most common, but there are many more supported). My experience with it has been that it is capable of exceptionally high availability and since it allows a stateful event-sourced application to be deployed as if it's stateless (e.g. in Kubernetes without needing an operator) there's a lot of deployment flexibility. Note that because it's built on the actor model, a lot of JVM observability tooling doesn't work particularly well with it (often assuming a stronger mapping of threads to tasks), so certain commercially-licensed observability tooling is recommended.
Additionally, Kalix also provides a polyglot (all you need is to express domain logic in a language which supports grpc) event-sourcing implementation.
Disclaimer: since answering this question (almost a year after answering this question), I became employed by Lightbend, the maintainers of Akka and provider of Kalix.
I am trying to figure out what's the difference between transferring dicom files with a (SCU/SCP) like pynetdicom3 vs using the wado api.
Both methods can be used for transferring dicom files. But I can't figure out what's the standard use case for each?
First of all, you can implement all common use cases with both approaches. The difference is rather in technology you are using and systems you want to interface with than in features supported by the one or the other approach.
The "traditional" TCP/IP based DICOM services have been developed since 1998. They are widely spread and widely supported by virtually all current systems in the field. From the nowadays perspective they may appear a bit clumsy and they have some built-in glitches (e.g. limitation to 127 presentation contexts). Still they are much more common than the web-based stuff.
Especially when it comes to communication use cases across different sites, it is hard to implement them with the TCP/IP based protocols.
The WADO services have been developed by the DICOM committee to adopt new technology and facilitate DICOM implementation for application based on web technology. They are quite new (in terms of the DICOM Standard ;-) ).
Having said that the major use case are web-based applications, I have not seen any traditional modalities supporting them yet, and I do not expect them to come up in the near future. This is because, you can rely on PACS supporting TCP/IP based DICOM but you would have to hope for WADO.
There is a tendency for PACS systems to support WADO in addition to TCP/IP to facilitate integration of web viewers and mobile devices where an increasing number of applications only supports WADO.
So my very subjective advice would be:
For an application that is designed for the usage within a hospital: Stick with TCP/IP based DICOM, since you can be quite sure that it will be supported by the systems you are going to interface with.
If connectivity via internet is a major use case, or your application uses a lot of web technology, consider using WADO but investigate the support for WADO among the relevant systems you need to interface with. This probably depends on the domain your application is targeting.
To add to the already very good answer by #kritzel_sw - WADO is only part of the picture. WADO is for retrieving images over the web. There's also STOW or STore Over the Web and QIDO or Query based on ID for DICOM Objects for storing new objects to PACS and querying the PACS respectively.
I think we will see it more and more in the future and not only for web based DICOM viewers, but also normal DICOM communications between the systems. It's especially useful for the cases where one of the systems is not DICOM aware and the developers are also not experienced in DICOM.
Consider a use case from my own experience. We want doctors to be able to upload photographs of skin conditions of their patients and send these photos to our PACS. It's much easier and probably cheaper to commision some developer to do it with STOW, where the specification is basically "take the JPG photo uploaded by the user, add necessary metadata in JSON format according to spec and send it all to this address with an HTTP POST request" rather than "convert uploaded JPG files to valid DICOM objects with the necessary metadata, transfer syntax etc and implement a C-STORE SCU to send it to our PACS". For the first job you can get any decent developer experienced in web dev, for the second you need to find someone who already knows what DICOM is with all its quirks or pay someone a lot to learn it.
That's why I love all these new web-based DICOM options and see great future for those.
I need to build a reliable predictive dialer based on Asterisk. Currently the system we use includes Wombat and Asterisk, and we do not find this solution usable as Wombat provides a poor API and it's impossible to use it without regular manual operations.
The system we want:
Can be used solely via API or direct database queries (adding lists to campaigns, updating lists, starting campaigns, stopping campaigns etc.) so that it can be completely integrated into an existing product
Is free, or paid for annually independent to the usage rate
Is considered stable
Should be able to handle tens of thousands of calls per day, if it matters
Use vicidial.org or hire freelancer to build new core with your needed api.
You can also check OSdial for this, it also developed using asterisk.
We have been working with a preview of the next version of Wombat, through the Early Access program, and Wombat has a complete configuration and reporting JSON API and you can deploy it "headless" in order to scale up to thousands of parallel lines. If you ask Loway they can likely get you access to the Early Access program.
BTW, Vicidial is great for agent-based outbound, but imposes quite a large penalty on the number of agents per server - you cannot reasonably use it to do telecasting at the scale we are looking for as it would require too many servers. Wombat is leaner and can drive over one thousands channel per server. YMMV.
This question would be better placed on a "hire-a-freelancer" site like oDesk ... if you need custom programing done, those are the sorts of places to go to get manpower.
Your specifications are well within what is possible with Asterisk. I'd strongly recommend looking at Vici Dial and OS Dial as others have suggested; out of the can, they are pretty good.
The hard part of any auto-dialer is not the dialer, oddly enough. It's the prediction algorithms, the answering machine detection algorithms and the agent UI. Those are what makes or breaks an auto-dialer application for a company.
Our company has people in every catastrophic event here in the U.S. and parts of Canada. An example is they were quite prevalent in Katrina immediately after the event.
We are constructing an application to improve their job in the field which may be either ASP.NET or WPF, and the disconnect requirement makes us believe it will be a WPF application. Our people need to be able to create their jobs, provide all of the insurance and measurement data, and save it as if in the database whether or not the internet is available.
The issue we are trying to get our heads around is that when at catastrophic events our people need to be able to use our new application even when the internet is not available. (They were offline for 3 days in Katrina)
Has anyone else had to address requirements like this and suggestions on how they approached functioning on small-footprint devices while saving data as if they were still connected to the backend services and database? We also have to incorporate security into this as well, and do it well enough that their entered data loads into the connected database without issues.
Our longterm goal is to also provide this application for Android and IPad Tablet devices as well as laptops. Our initial desire for ASP.NET was it gave us an immediate application for the tablet environment. In the old application they have, they run a local server, run remote connections on the tablets and run the application through terminal server. Not pretty. Not pretty.
I feel this is a serious question that is not subjective so hopefully this won't get deleted.
Our current architecture on the server side is Entity Framework with a repository pattern, WCF services to satisfy CRUD requests returning composite data transfer objects, and a proxy for use by the clients.
I'm interested in hearing other developers' input and this design puzzle.
Additional Information Added to the Discussion
Lots of good information provided!!! I'll have to look at Microsoft Sync for sure. For the disconnected database I would be placing only list tables (enumerations) in the initial database. Jobs and, if needed, an item we call dry books, will be added for each client we are helping. (though I hope the internet returns by the time we are cleaning and drying out the homes) These are the tables that would then populate back to the host once we have a stable link. In the case of Katrina we also lost internet connectivity in our offices which meant the office provided no communication relief for days as well.
Last night I realized that our client proxy is the key to everything working! The client remains unaware of the fact that it is online or offline and leaves the synchronization process within that library. We are discovering how much data we are talking about today. I also want to make it clear that ASP.NET was a like-to-have but a thick client (actually WPF with XAML) may end up being our end state.
Now -- for multiple updates. The disconnected work will be going to individual homes by a single franchise. In fact our home office dispatches specific franchises to specific events. So we have a reduced likelihood (if any) of the problem of multiple people updating a record. The reason is that they are creating records for each job (person's home/office/business) and only that one franchise will deal with it. Of course this also means that if they are disconnected for days that the device that creates the job (record of who, where, condition, insurance company, etc) is also the only device that knows of the job. But that can be lived with. In fact we may be able to have a facility to sync the franchise devices on a hub.
I'm looking forward to hearing additional stories of how you've implemented your disconnected environment.
Thanks!!!
Looking at new technology from Microsoft
I was directed to look at a video from TechEd 2012 and thought I might have an answer. The talk was on using ASP.NET and MVC4 along with 2 libraries for disconnected behavior. At first I thought it would be great but then as it continued it worried me quite a bit.
First the use of a javascript backend to support disconnected I/O does not generate confidence. As a compiler guy (and one who wrote two interpretive languages) I really do not like having a critical business model reliant upon interpretive javascript. And script at that! It may be me but it just makes me shudder.
Then they show their "great"(???) programming model having your ViewModel exist as just javascript. I do not care for an application (asp.net and javascript) that can be, and may as well be (for lack of intellisense ) written in notepad.
No offense meant to any asp lovers, but a well written C# program that has been syntactically and type checked gives me stronger confidence in software than something written with a hope and prayer that a class namespace has been properly typed without any means of cross check. I've seen too many hours of debugging looking for a bug that ended up in a huge namespace with transposed ie in it's name. I ran my thought past the other senior developers in my group and we are all in consensus on this technology.
But we continue to look. (I feel this is becoming more of a diary than a question) :)
Looks like a perfect example for Microsoft Sync Framework
http://msdn.microsoft.com/en-us/sync/bb736753.aspx
A comprehensive synchronization platform that enables collaboration
and offline access for applications, services, and devices with
support for any data type, any data store, any transfer protocol, and
any network topology.
I often find that building a lightweight framework to fit my specific needs is more beneficial to me than using an existing one. However, always look at what's available and weigh the pros and cons before making that decision.
I haven't use the Microsoft Sync Framework, but it sounds like that's a good one to research first. If you have Sql Server Standard (or some other version other than the Express version) then replication might also be an option.
If you want to develop your own homegrown solution, then be sure to put lastupdated and dateadded fields on any tables that need to stay in sync. It doesn't 'sound' like your scenario will be burdened by concurrency issues (i.e. if person A and B both modify a field at the same time, who wins?). If that's the case then developing your own lightweight solution will be pretty straightforward.
As Jeremy pointed out, you will need a way to get the changes. In addition to using a web service, you can also use WCF which is similar to a web service in some ways. But my personal bias would be towards just accessing a SQL server remotely over the internet. The downside of that solution is added security concerns, while the upside is decreased development overhead (i.e. faster/easier development now and less maintenance over time). Also, the direct SQL solution is also assuming that this is an internal application... that you're in charge of all development and not working with 3rd parties who need access to your data and wouldn't be allowed to access it this way.
Not really a full answer but too much for a comment.
I have two apps one that synchs one way and the other two way.
I do a one way synch to client for disconnected operation. At the server full SQL Server and at the client Compact Edition. TimeStamp is a prefect for finding any rows that needs to be synched. I also don't copy the whole database as some of the largest table are non nonessential. The common use is the user marks identified records they want to synch.
If synch does what you need great +1 for Jakub. For me I don't have the option to synch the whole MSSQL both based on size and security.
Have another smaller application that synchs two way but in this case it has regions and update are only within the region. So a region only synchs their data and in disconnected mode they can only add new records. Update to an existing records must be performed in connected mode. That was mangeable. In that case MSSQL for the master and used XML for the client.
No news to you but the hard part of a raw synch is that two parties may have added or revised the same record.
"What makes a good BizTalk project" is a question I was asked recently by a client's head of IT. It's rather open ended, so rephrasing it slightly to :
"what are you top ten best practices for a BizTalk 2006 and onwards projects - not limited to just technical practices, eg organisational"
I wrote an article called "Top 10 BizTalk Server Mistakes" that covers some key best practices in terms is usable information rather than a simple list. Here's the listing:
Using orchestrations for everything
Writing custom code instead of using existing adapters
Using non-serializable types and wrapping them inside an atomic transaction
Mixing transaction types
Relying on Public schemas for private processing
Using XmlDocument in a pipeline
Using ‘specify now' binding
Using BizTalk for ETL
Dumping debug/intermediate results to support debugging
Propagating the myth that BizTalk is slow
...and the link to the complete article: [Top 10 BizTalk Server Mistakes] (http://artofbabel.com/columns/top-x/49-top-10-biztalk-server-mistakes.html)
The key point is to emphasize to the client that BizTalk is a swiss army knife for interop... an expensive swiss army knife. A programmer can wire up two enterprise systems with a WCF application as fast as you can with BizTalk. The key things to include/require when using BizTalk is to:
Have more than simple point integrations. If this is all you have, fine, see the rest.
Have all or a portion if a process that is valuable going theough BizTalk so that you can instrument it with BAM and provide process monitoring to the organization... maybe even some BI.
If you are implementing a one to many or many to one scenario, use of the BizTalk ESB patterns will pay deividends in th elong run
When there are items that need to be regularly tweaked - threshholds, URI'ss, etc... use of the Business Rules Engine can provide an easily maintainable solution.
When endpoints might be semi connected, BizTalk bakes in queueing of messages for no extra effort.
Complicated correlations or ordering of messages.
Integrating with exisitng enterprise systems can be simplified with the adapter packs provided as part of BizTalk. This alone can save big bucks. Asking Oracle, PeopleSoft or Siebel folks about XML and Web Services can be a challenging experience. The adapters get you and BizTalk through the enterprise apps' front door and reduces the work for themsignifcantly.
There are more I just can't think of at midnight.
Any of these items make BizTalk a winning candidate because so much of it is given to you with the platform. If you are not being required to provide any of these, you should really attempt to deliver some of these beneftis in highly visible way to the client. if you don't it's just an expensive and under utilized swiss army knife.
I'll start with Environment and Deployment Planning. Especially testing deployment and matching your QA/Stage (whatever the pre-production environment is) to the production environment so you don't find out some weirdness at midnight when you are trying to go live.