I have noticed that webMethods ActiveTransfer has had problems when handling large files. For example, when we receive (and perform operations on) files that are larger than about 16 MB, the software starts losing performance. This is why, for most customers who have to deal with big files, I suggest that they use a product other than ActiveTransfer. I would like to note that this problem mainly concerns large files that undergo extra operations, such assigning, unassigning, or file translation. When these operations take place on large files, ActiveTransfer will use up a lot of resources. Within the product itself, I also believe that there is room for improvement in terms of optimization when it comes to general performance. I suspect that the issues underlying poor optimization are because it is all developed in Java. That is, all the objects and functions that are used need to be better organized, especially when it comes to big files but also overall. webMethods ActiveTransfer was born as an ESB to handle messages, and these messages were typically very short, i.e. small in size. A message is data that you have to send to an application, where it must be received in real-time and possibly processed or acknowledged elsewhere in the system as well. So, because it was initially designed for small messages, it struggles with performance when presented with very large files. All this to say, I suggest that they have an engineer reevaluate the architecture of the product in order to consider cases where large files are sent, and not only small ones. As for new features, compared to other products in the market, I think Software AG should be more up to date when it comes to extra protocol support, especially those protocols that other solutions have included in their products by default. Whenever we need to add an unsupported protocol, we have to go through the effort of custom development in order to work with it. Also, all the banks are obligated to migrate to the new standards, and big companies are all handling translations and operating their libraries with the new protocol formats. But webMethods ActiveTransfer doesn't seem to be keeping up with this evolution. Thus, they should aim to be more compliant in future, along the lines of their competitors such as IBM and Primeur.
Integration Administrator at Sainsbury's Supermarkets Ltd
Real User
Top 10
2022-06-06T19:10:00Z
Jun 6, 2022
Some things could be improved, especially how ActiveTransfer handles third-party file transfers. It would be nice to have a native file-watching mechanism for when you're scheduling jobs with a third-party scheduler. Currently, we are using an outside file watcher solution to check the files before the file transfer. It checks the location to see if the file is there. If the file is there, it will prepare it for transfer. If the file isn't available, it will send an email it can create a ticket send it now. We recommended adding this file watcher mechanism. Also, when we're dealing with massive files, ActiveTransfer requires huge amounts of RAM, but if would be helpful if we could customize the compression and encryption to squeeze that data and reduce the size to save on system resources.
I have noticed that webMethods ActiveTransfer has had problems when handling large files. For example, when we receive (and perform operations on) files that are larger than about 16 MB, the software starts losing performance. This is why, for most customers who have to deal with big files, I suggest that they use a product other than ActiveTransfer. I would like to note that this problem mainly concerns large files that undergo extra operations, such assigning, unassigning, or file translation. When these operations take place on large files, ActiveTransfer will use up a lot of resources. Within the product itself, I also believe that there is room for improvement in terms of optimization when it comes to general performance. I suspect that the issues underlying poor optimization are because it is all developed in Java. That is, all the objects and functions that are used need to be better organized, especially when it comes to big files but also overall. webMethods ActiveTransfer was born as an ESB to handle messages, and these messages were typically very short, i.e. small in size. A message is data that you have to send to an application, where it must be received in real-time and possibly processed or acknowledged elsewhere in the system as well. So, because it was initially designed for small messages, it struggles with performance when presented with very large files. All this to say, I suggest that they have an engineer reevaluate the architecture of the product in order to consider cases where large files are sent, and not only small ones. As for new features, compared to other products in the market, I think Software AG should be more up to date when it comes to extra protocol support, especially those protocols that other solutions have included in their products by default. Whenever we need to add an unsupported protocol, we have to go through the effort of custom development in order to work with it. Also, all the banks are obligated to migrate to the new standards, and big companies are all handling translations and operating their libraries with the new protocol formats. But webMethods ActiveTransfer doesn't seem to be keeping up with this evolution. Thus, they should aim to be more compliant in future, along the lines of their competitors such as IBM and Primeur.
Some things could be improved, especially how ActiveTransfer handles third-party file transfers. It would be nice to have a native file-watching mechanism for when you're scheduling jobs with a third-party scheduler. Currently, we are using an outside file watcher solution to check the files before the file transfer. It checks the location to see if the file is there. If the file is there, it will prepare it for transfer. If the file isn't available, it will send an email it can create a ticket send it now. We recommended adding this file watcher mechanism. Also, when we're dealing with massive files, ActiveTransfer requires huge amounts of RAM, but if would be helpful if we could customize the compression and encryption to squeeze that data and reduce the size to save on system resources.