webMethods.io Reviews

Clients choose webMethods.io API for its intuitive interface, promoting seamless interaction and quick communication between systems. The platform's focus on rapid deployment expedites time-to-market, while robust governance features ensure control and compliance. Particularly appealing to less mature clients in API management, it offers a strategic toolset for gradual integration advancement, providing both immediate benefits and a pathway for long-term growth.

A potential drawback of webMethods.io API is its adaptability to legacy systems, which can vary in compatibility. This becomes evident when dealing with diverse products within a client's portfolio, requiring significant time and resources for API integration. The challenge lies in the need for a robust team and cost optimization to bridge the gap between legacy systems and modern API standards. Additionally, the time and effort involved in transforming products into API-ready formats can be a limiting factor. While the platform offers comprehensive solutions, addressing these challenges requires careful consideration and a modular approach for optimal results.

I have been working with webMethods.io API for a year.

webMethods.io API is stable, but its maturity may not meet all customer expectations due to the challenges of dealing with large legacy systems. Achieving optimal results takes time and gradual refinement as the platform evolves to address these considerations. I would rate the stability as a seven out of ten.

Scalability is webMethods.io API's strong point. The solution is designed to scale seamlessly, offering flexibility from small to medium and up to enterprise-level clients.

The tech support from webMethods is solid, and I would rate it at nine out of ten.

Positive

The installation of webMethods.io API is flexible, offering options for both on-premise and cloud deployment. The customer has the capability to choose either based on their preferences and security requirements. However, a crucial condition for product ownership is having your own cloud infrastructure. Without this, selling the solution may face challenges due to country-specific regulations. It is not just a customer requirement but a regulatory necessity to align with the country's guidelines. The deployment time for webMethods.io API varies based on the scope. For upgrades, it typically takes six to eight months, while total implementations can range from 12 to 18 months. The number of engineers and architects needed depends on factors like chosen modules, domains, and the scale of customer service, ranging from thousands to millions. Once deployed, maintenance is relatively easy.

The solution is on the expensive side in terms of pricing. It follows a yearly licensing model. Clients typically pay for the license only if they have the internal capacity for implementation. However, for a more comprehensive approach, clients often opt for additional services, including implementation, maintenance, and support from the vendor's side, especially when the scale of the project requires a more hands-on approach.

Before choosing webMethods, it is crucial to assess your organization's skill set. The solution is powerful and scalable, especially for large enterprises, but smaller businesses might find it challenging both in terms of cost and resource availability. It is a robust choice for those with substantial needs and the capability to leverage its features effectively. Understanding your organization's scale and capabilities is key to making the most of what webMethods has to offer. Overall, I would rate webMethods.io API as a nine out of ten.

There are many use cases for webMethods ActiveTransfer, but the main focus for us is transferring files internally between applications or externally between partners. From a technical point of view, it can be seen a tool for file transfer for A2A (application-to-application), and from a market model point of view, it's also a B2B (business-to-business) tool. In terms of extras, it includes an engine for translation, which comes as an add-on, so that customers can translate files as they send or receive them from external partners. We could, of course, also create a custom interface in order to allow physical users to perform file transfer, but this is not a common use case.

Using webMethods ActiveTransfer, we can create rules for automatic application-to-application file transfers, and one of our customers in Italy is even using it for both file transfers and as an ESB (Enterprise Service Bus) as part of their supply chain infrastructure where there is a very high volume of messages being exchanged (thousands and thousands of messages per day).

If the customer's infrastructure is complex, with high-availability clusters and so on, then we often have to implement not only the basic use case, but also consider other business cases as well, such as in our Italian customer's situation where ActiveTransfer must additionally communicate with their order management orchestrator and other parts of their infrastructure.

There are offerings for deployment on cloud or hybrid as well, but most of the customers who have around 1,000 employees prefer the solution to be situated on-premises.

The core product can be used not only for automatic file transfers between applications, but also as an Enterprise Service Bus (ESB). Internally, it's easy to exchange messages between applications because they have decent integrations of message protocols whether you're using a REST API or MQ. Thus, its core functionality is highly compatible with different methods of exchanging messages between applications.

On the whole, it's a very good product being all at once easy to use, easy enough to install, and easy to deploy new workflows and so on.

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.

I have been working with webMethods ActiveTransfer for four years. In the beginning I was working directly with the product, handling technical aspects, and now I am in more of a managerial role, managing teams in the implementation of new projects.

For the most part, it's very stable and I would give it 4/5 stars.

The stability issues only arise in more extreme cases, such as when the file sizes are too large for the infrastructure to handle, or when the infrastructure is not well designed. And sometimes the problems are simply due to the fact that there isn't adequate performance on the other machine. In my books, the processing time for a 20 MB file should be measured in milliseconds or seconds, not minutes.

It's scalable, but my rating would only be 3/5 stars for this aspect. In general, the scaling is easy to implement when it comes to adding more resources to a machine, but when adding new nodes and so on, it's definitely not as easy as its competitors. There's a lot of manual activities that must be done, and it's not just a simple matter of running some scripts to start a cluster with new nodes.

This is, of course, the on-premises version I am talking about. I have not yet worked on the hybrid solution, though from what Software AG has sent me, it seems a lot easier because it deals with containers rather than nodes.

We don't have any major issues with their support, but more often than not they take a very long time to answer. Because I work frequently with the sales team and other highly technical staff on their side, I eventually manage to solve most of the issues we come across by talking with them instead of support.

So most of the time, we do have our problems solved, but typically not with the speed and precision that we need.

Neutral

In terms of initial setup, It's easy enough and I would rate the process 4/5 stars.

How many engineers and other staff we need for deployment is always based on customer requirements, of course. For a simple business case comprising a non-complicated infrastructure with only a standard load node for production and a standard load node for staging, webMethods ActiveTransfer can be installed and set up by just one engineer within three or four days.

If the infrastructure is more complex, with high-availability clusters and multiple business cases to be implemented, then the deployment can extend over two or three weeks under the care of a senior staff member. 

From a service point of view, the staff needed for deployment, maintenance, and support also depends on the SLA with the customer. For example, one of our customers in Italy uses webMethods ActiveTransfer not only as a file transfer system, but also as an ESB that is integrated with their supply chain infrastructure. In this case, keeping ActiveTransfer up and running is critical and we must provide extended support with two people from 8:00 AM to 4:00 PM, and then another two people from 4:00 PM to midnight.

The ROI differs for each customer. As an integrator in Turkey, we see that if the customer is going to use webMethods ActiveTransfer to integrate multiple different business cases, the ROI is quite good, and it can be a positive ROI in only a matter of months.

In other cases, if the customer purchases a large amount of infrastructure in order to implement multiple workflows, but for internal reasons they have to move slowly, then over time the ROI is much greater.

However, it's very difficult to give an estimate on ROI because it depends so much on each individual customer. It's a good, complete product, but it's not cheap. In fact, it's among the top three or four most expensive platforms on the market and for this reason it's not always ease to achieve a very high ROI.

The licensing depends on the type of customer, so I would refrain from talking about it in an absolute kind of way. Overall, it's somewhat expensive, and depending on customer requirements, there are different types of licensing that can be useful, or not so useful.

Their licensing options are a mix with some variety between them. Normally, the on-premises license is a perpetual license, where the customer purchases the licensing once and then in following years only has to pay for the support. However, they have also included other licensing structures in which you can choose your licenses according to the number of users or the specifications of the machine that it will be running.

Sometimes we don't have a very clear idea what the licensing will entail at first, because it can be very customizable. On one hand, this can be a good thing, because it can be tailored to a specific customer's needs. But on the other hand it can also be an issue when some customer asks, "What's the cost?" and we can't yet give them an accurate answer. In times like these, we can only tell them that it depends on your use case, and this isn't always the answer they want to hear. 

During my career I have worked with a lot of different products and I generally only go on to work with those products that I feel are worth being called good products. We also work with IBM and Primeur, and I can say that webMethods ActiveTransfer is a very good product. It's easy to use, and easy enough to install and deploy new workflows.

At the same time, since we have been having numerous issues with their support in terms of response times, I must say that if their support doesn't improve, we may eventually have to stop promoting this product to our customers.

I would rate webMethods ActiveTransfer an eight out of ten.

By Software AG, we are also using Integration Server, Trading Networks, Active Transfer, Optimize for Infrastructure, My webMethods, and their EDI package. As long as there is product parity between products, it makes sense to continue using multiple products from the same vendor. Obviously, you want to make sure you have a diverse portfolio. Where those products start breaking those links, you want to make sure that you are using the best product for your company in this region.

The fact that we were already using another solution from this vendor affected our decision to go with this particular product, mainly from a cost standpoint. As is any product in this region, the biggest cost is almost always the upfront cost of laying out the solution. Also, there are some costs in having that solution already available: between knowledge of the platform, having the licensing rights, and if you bring in a new solution, then you are now paying for two solutions.

The native integrations between the vendors' products are very seamless. The products interact very well. At times, it's kind of hard to tell where one product ends and the next one starts. As new products come in, the integrations probably take one or two updates before they are fully integrated. However, once products are fully integrated, it is very seamless and easy to hop between one product to another.

Using multiple products from the same vendor creates efficiencies:

1. In terms of knowledge. Obviously, there is a familiarity with the product and how you expect Software AG's products to act and respond. 
2. In terms of operational understanding between end users who are looking for specific data. They know how these products work and how to pull up these reports. 
3. In terms of having administrators overseeing these products.

There is a cost savings for using many of the same products. There are lower training costs. Also, typically, there are a lot of integrations that you ended up needing to build out, whether they be custom or out-of-the-box. Even if they are out-of-the-box, a lot of times that takes a lot of work to get those to work. However, since we are using Software AG products, it's very much like installing a plugin into an Excel program.

There was a reduction in the learning curve because we had already used the vendors' products. The products used work very similarly. In terms of verbiage, key aspects, or three-letter acronyms, you don't have to relearn any of those. There is an expectation of how these products will work. These products always work the same way when Software AG is rolling these types of products out.

We use webMethods Integration Server for two main aspects: 

1. For application-to-application integrations.
2. B2B: The transferring of on-premise data out to other business partners.

As with any integration platform, it is a single pane of glass that allows you to see and interact with transactions as they are flowing. Out-of-the-box, Software AG offers robust monitoring solutions to help you understand if a solution's up or down transactions aren't working, etc. The tool has been invaluable to our organization in terms of understanding where our data is, how it's flowing, and its current status.

Having a single hybrid-integration platform for all our needs is very important. From an IT perspective, it is a way for us to easily troubleshoot and quickly resolve issues. From a business perspective, it's very important because IT is readily available to assist with any system issues which are happening at that time. Anytime that you have applications talking to each other, it is a breeding ground for problems and issues. Having a solution like webMethods Integration Server in place can empower your IT department to be able to resolve issues and roll out solutions quickly as new applications come into your portfolio.

We have been on webMethods Integration Server for 15 years. We just got rid of our mainframe. It works wonders with our mainframe. With SaaS and cloud applications, webMethods Integration Server does not answer this need by itself. This is where you would be looking for APIs or custom plugins to work with those types of solutions. 

It is very open. It is extremely rare for us to find something that we are trying to integrate, but we can't integrate it. In the past seven years, I don't think that has ever happened. For any problem that we are looking at, the Software AG solution can solve. That has probably been the most valuable feature.

Application integrations are offered out-of-the-box, and that is extremely important to us. This is one of the main use cases that we have for it. It is about 60 to 70 percent of the workload in our application today.

Integration platform as a service (iPaaS) is probably the future and direction that many companies and organizations are looking at. Software AG is also rolling out robust solutions for this. So, if I was a brand new customer, that is where I would be looking. This is also the direction that I think Software AG is moving into along with almost every vendor in the industry. However, the integration platform, as it currently sits, runs really well. It's very robust and does what you would expect it to do.

My organization moved onto the webMethods platform 15 years ago. I have been using it for the past seven years.

Software AG is a partner who has been around for many years. The company is not going anywhere. Regarding the solution, you can get the capabilities that you need out of it.  It is a known solution that works really well and does exactly what you would expect it to do.

Software AG's full support for the solution’s adapters and connectors brings long-term stability to our services and integrations. Software AG has many SMEs in each region, both globally and in each product type. Being able to have access to a subject-matter expert in the specific tool or region that I'm looking for is invaluable. I feel like I am talking to someone who has hands-on experience in either developing the solution or has many years of experience with the product or similar customers. They also have people who just work in specific business groups. For example, if I'm looking for a knowledge worker to do something with IoT, then they have people ready who can answer specific questions about products that we might be looking to integrate with.

The solution is very scalable. If you want more webMethod Integration Servers, it is very easy to spin them up. It's very easy to apply packages to each one of those solutions. Or, if you want to just have one large webMethods Integration Server, it is easy to create the configuration settings to allow that JVM to have more memory.

There are less than 20 users. A solution like this is normally a back-end solution. Obviously, we have administrators who are overseeing the product to make sure it's up, patched, available, and secure. Developers who are rolling out new solutions and debugging any issues going on in production or lower environments. Then, the third group is probably the business users. That is a very small hand full of users at our company. Those users are typically looking just to make sure that the data is flowing as they would expect. For example, I expect a certain file to go out to this customer every day. That business user has access to log into the application and pull that file.

The product is used extensively at my organization. Out of all our integrations, it probably counts for 60 to 70 percent. Every minute of every day, it's being used. I think the usage that we have in place today is correct. If we were to expand any further, we would probably be looking at iPaaS solutions.

Their technical support is very good. I have never had any issues with the support or getting the resources that I need.

Two months ago, Software AG did have a data breach, so their support desk got shut down. It has been down since then, and that has not been a pleasant experience. Prior to that, it was a pleasant experience. I think Software AG has been reeling from that, but there are ways to get a hold of their support desk. This ensures that their customers still have access to support, which has been available and out there. However, they did have a public exposure, which has ended up causing some loopholes for their customers.

Upgrades are complex. They typically take about five months from start to finish. There are many packages that plug into webMethods Integration Server, which is the central point for a vast majority of the transactions at my organization. Anytime we are upgrading that, there are complexities within each component that we must understand. That makes any upgrade very cumbersome and complicated. That has been my experience at this company. Because there are many different business units that we are touching, there are so many different components that we are touching. The amount of READMEs that you have to go through takes some time.

This is where we would need to look at an iPaaS solution or moving to work with microservices solutions. Obviously, the smaller you make the solution, the more you're able to in an agile fashion.

From a high-level implementation strategy, we do a waterfall approach. That is the approach that we have ended up following for upgrading this solution.

Deploying solutions is very easy. The biggest thing that any company has to look at, because we have had a couple of pitfalls in this, is you have to look at how you're rolling your solution out. So, if you end up stacking or creating common services in the solution, those solutions become very tricky as they start to age, as any development cycle would end up having. The smaller you create the solution, the easier it is to keep rolling out those solutions, and staying away from common services really allows you to continue to roll out with ease.

As new solutions roll out or there is a different way for these apps to integrate, it has been fairly easy for developers to make the modified changes needed. The biggest thing is always knowledge because there have been some integrations that haven't been touched for 15 years. Then, if someone needs to touch one of those integrations, there is a learning curve in understanding how that integration works and what they are looking at.

Having a product like this is invaluable to any company in terms of the amount of time that IT gets to save in terms of integrating different products as well as having an open way to ensure that these applications are working. If you were to do this out of the box for each one of those solutions, while the upfront costs would be cheaper, the long-term stability of your applications would definitely degrade. As you are rolling this out for products that probably run your business, that's probably not a direction that any long-term company would want to go. I know my organization has seen time savings from not going with in-house built integrations from app to app.

For the B2B, we are probably saving somewhere between five to 10 full-time resources who would be working on this manually. For application-to-application, it probably has cut down 50 percent of our downtimes at a minimum. When you're talking about application-to-application integration, that is the thing that you would probably end up using as a key metric. For the amount of downtime that we have, I would double the amount or length of downtime that we would have if we didn't have this solution.

Currently, the licensing solution for this product is pretty straightforward. The way that Software AG has moved in their licensing agreements is very understandable. It is very easy for you to see where things land. Like most vendors today, they are transaction based. Therefore, just having a good understanding of how many transactions that you are doing a year would be very wise. Luckily, there are opportunities to work with the vendor to get a good understanding of how many transactions you have and what is the right limit for you to fall under.

With any solution like this, on day one you have a project that you're trying to work on, but just understand where you are trying to go with the solution. Some plugins are cheaper than others, and others are more expensive than others. Just make sure that you understand the full scope of what you might end up using the product for, so you can understand the all-in costs.

The tool works extremely well. Software AG offers packaged solutions for many packaged apps. Oracle SQL Server or Salesforce are add-ons that you can purchase and install easily for plug and play with packaged solutions. When you start moving into custom applications, there are no packaged solutions. The good news is that typically custom apps are built in some type of known technology, and that technology can easily be integrated into webMethods Integration Servers.

Business-to-business communications is an add-on that needs to be purchased. While super important to my organization, it is an add-on outside of the standard webMethods Integration Server. I would strongly recommend the business-to-business add-ons, especially if you're looking to use webMethods Integration Server in that capacity. It just makes the development cycles a lot shorter as well as making it much easier to manage your business profiles.

We routinely evaluate other options. I wasn't here when we made the decision to move onto this solution, but we periodically reassessed the platform to see if we are still sitting on the best solution that is matched to our corporation.

Today, there are many newer solutions out in the marketplace, and Software AG does offer those solutions. That is a great start. If I was starting over, I might look at those alternative solutions. However, if you are an alternative solution to webMethods Integration Server (not Software AG), then I would probably be looking a lot more into the cloud. webMethods Integration Server is used in a very legacy way. For example, we are on premise with data centers, which are legacy ways to solve a problem. If my solutions were in the cloud, then I would probably be looking at webMethods Integration Cloud as Software AG offers it, or any of the other vendors, like MuleSoft. So, you have to look at:

• What am I trying to integrate today? 
• Where are those solutions sitting? 
• If everything is on-prem and you are a 110-year-old company with 50 plants across the place, then probably having an on-prem is the right solution.
• If you are an eCommerce shop, then you are probably looking more in the cloud and for a cloud solution.

The solution pays for itself, but it is complicated as it stands today. Make sure that you are using it for exactly what you have architected it for. Don't try to fit a square peg into a round hole.

We have been moving away from data integration for webMethods Integration Server. So, it's becoming less of a priority for us.

Software AG has been moving in the direction of trying to make their tool as modern as possible. It has plugins for Docker today as well as ways to integrate into webMethods Integration Cloud. While these integrations are available, we don't use them.

I would rate webMethods Integration Server as a seven (out of 10). For what the solution can do, it does it extremely well. The upgrades are very cumbersome; they are very long and disruptive. You have to do them at least every three years. It's not a fun time for any company. If upgrades were a 100 times easier, it would get a much higher score.

The product supports various types of digital documents, including XMLs and EDI.

One area that needs improvement is the version upgrade process. Many customers I've worked with encounter challenges when transitioning from their current version, such as x or 9, to a newer version. The process is not smooth, and they must shift their entire website. If I am part of the consultancy company, I could propose taking on the version upgrade process as a separate project. From the company's perspective, this upgrade could vary in duration depending on the complexity of the business, ranging from six months to a year. This extended timeframe poses a significant challenge for customers due to the competition. From a cost perspective, getting the money for the upgrade project can be challenging for customers. 

I have been using the product for a couple of years. 

The product's on-prem version is more stable. The cloud version was introduced only recently and will take time to establish itself. I rate its stability a six out of ten. 

The solution's on-prem version is scalable. I am not sure about the cloud version since everything is controlled by the product. My company has 500-600 users. As a consultancy business, we offer solutions to clients across different countries who seek to implement network solutions.

We often contact support for assistance when we encounter challenges, especially with the cloud version. We rely on our extensive community resources and past experiences for on-premises solutions. However, when issues persist beyond our capacity, we escalate them to support for resolution.

The tool's deployment is not straightforward. Indeed, the deployment duration hinges on the complexity of the organization's size. Certain components may facilitate swift upgrades, while others, such as the API gateway, often take longer.

The deployment process is smooth and doesn't come with any standardized guidelines. Developers can do it as per their approach. Six steps can be used to deploy the tool. You would need two to three resources to handle its deployment and maintenance. 

The solution's development license is free for three to six months. We have to pay for other things. 

I have completed several integrations using the webMethods Integration Server. One recent project involved the supply chain industry, specifically working with tracker and shipping companies involved in container movement. We developed a B2B platform for various stakeholders. This platform facilitated data storage and transaction tracking for different partners. It was implemented as a SaaS solution built on the webMethods Integration Server.

Recently, they introduced a cloud version of the B2B platform, which has potential but is still in the early stages of development and is not yet stable.

The Flow language is an old but effective tool, especially in webMethods Integration Server. I started using it quite early in my career. With Flow language, you don't need to visualize everything in your mind before coding. It allows for rapid development.

The on-prem version can handle volumes of transactions. We encounter challenges when the client's requirements are not clear. 

I rate the product a seven out of ten. 

This is an integration tool along with its having IoT applications and data integration applications.

The main benefit of this product is the speed of the development process and the speed of the business. It has a good integration server and a very good API portal. WebMethods has the tools to develop everything you need and the custom code is relatively easy. It makes the development, the product, and the business more efficient. This is a very strong and useful tool.

The orchestration is not as good as it should be and needs to be improved. 

I've been using this solution for three years. 

The stability is very good. 

Scalability is very good on the cloud but a little difficult for the on-prem version because it requires the creation of one integration server and booking the code on a second integration server, and creating a cluster between them. 

I've contacted technical support many times. Their response is very fast and they provide good service. We've only ever had one time where they were unable to solve an issue we had. 

The initial setup is easy. We deploy both on-prem and cloud, and both are straightforward taking less than 10 minutes. For on-prem implementation, there is a deployer and for the cloud, we use OpenShift. The deployment requires one person and the product doesn't require any specific follow-up maintenance. 

When compared to other solutions, we found the task engine to be better in webMethods along with the ease of development. 

I recommend this solution and rate it nine out of 10. 

Today, we work with many financial organizations worldwide, and sometimes they have Legacy software, so we use webMethods Integration Server in those cases. 

We are not resellers, but we provide solutions to large financial institutions, and sometimes we have to work with a lot of legacy software. Sometimes we have webMethods Integration Server as part of the stack. Sometimes we do consulting, and sometimes we take ownership of parts of the projects that large financial institutions have.

webMethods Integration Server is very similar to every integration product in the world, and in the past, we used to write point-to-point connectors with the concept of ESB. We used hub and spoke architectures, and webMethods Integration Server would be used in that context.

Usually, the way large enterprises work is they acquire different licenses over time, so we check their internal IT asset management software in terms of their licenses. If they already have a webMethods Integration Server license, we use that as part of our solution.

Otherwise, we would make recommendations to them on what to acquire in the open market. If the solution is cloud-based, we recommend that they use cloud-based ESB software to integrate different components of their solution. We choose different software pieces, put them together, and ensure that they add value on top of the integration headaches that come when you work with enterprise software.

webMethods Integration Server benefited our organization. If it didn't, then we would not be using it.

What I like best about webMethods Integration Server is its portfolio of connectors. Every integration product has different components to interact with SAP, Salesforce CRM, etc. My organization includes the type of connectors a product has, apart from license availability, usage, and so on, as the criteria for choosing or recommending a solution.

In terms of the feature set, any integration software you use will have to connect different components of enterprise software. Depending on the enterprise software a financial institution, such as a bank, will be using, my company first checks the available connectors in the product, product maturity, and what other solutions can be integrated with the product before making a recommendation to either reuse the product if you currently have a license for it, or purchase a license if you don't have the license yet.

For example, when an enterprise invests in SAP or Salesforce CRM software, that investment is very significant. When you need a form of interaction to exchange data, that's when you use an integration product, so I'm saying that the actual value of integration software, such as webMethods Integration Server, is its ability to connect with other enterprise software.

webMethods Integration Server is no longer that popular because the market has started moving towards cloud-based ESB solutions from Azure, AWS, and other vendors, so this is one area for improvement.

As I mentioned, the real value for any enterprise integration software, especially a proprietary platform such as webMethods Integration Server, will be in the number, quality, and stability of the connectors it has. That is the most critical aspect of every ESB product in the world. Sometimes, what happens is in case a particular connector is not available between a proprietary component within a bank or a financial institution. My organization would have to develop the software components, so what would be ideal is if there was a core set of software that's open source, which would make it easy for third-party vendors and individuals to build components to fill in the gap. This is what I would recommend.

The market webMethods Integration Server falls under is a very crowded market, so for the product to stand out, Software AG would need to get traction in the open source community by releasing a new version or a base version and open source it, so people can create new custom components and add it to the portfolio.

I would recommend looking at Apache ServiceMix or Apache Camel, ESB products, or enterprise software products for integration and looking into the open-source mechanism. MuleSoft is another example, as it has an open-source base version and an enterprise version sold to enterprises. Mulesoft has many open-source components but allows third-party vendors and ISPs to create custom components for customers.

This is the feature set I would suggest for webMethods Integration Server because it's what the product needs to survive in the integration space. Otherwise, other solutions, such as Apache Camel, will take over the world.

I've used the webMethods Integration Server on and off for a long time. The product has been around for quite a bit. I evaluated it once my friend sent me a copy of it a long time back and made me a beta tester for the product. I've used it on and off.

webMethods Integration Server has been around for quite some time, so it's a very stable solution. It's much more stable compared to newer entrants in the market.

For software to be stable, it has to be deployed. It has to be created, developed, tested, and deployed in production. Then, it'll be patched and versioned across multiple years, so the more versions a solution has, the more bugs have been removed in the core system, making it much more stable than newer competitors. Again, this is a case-to-case basis, but you can generally use this as a rule of thumb. The longer the software has been there, the more stable it is.

This is why the backend payment systems are written in COBOL in almost every top financial organization or bank you walk into. Even though COBOL is practically a dead language, it's very stable because it's been in production, and it's been tested, verified, and used; plus, its bugs have been fixed over a long period, so you have very, very stable systems that run on COBOL.

Different people view scalability differently, but with webMethods Integration Server, what's happening is that you have cloud-based tools that make the solution far more scalable.

From a webMethods Integration Server point of view, as long as there's a load balancer in front with clustered mechanism, then it should be good to go. Still, the real key is how much of the transformation occurs in integration scenarios, the volume of transactions, the number of transformations, and content-based routing, which affect performance and scalability.

A good example is when you must put a highway to handle the traffic load it is typically expected to serve. You don't need to make it very, very scalable. If you're integrating the product with internal components in SAP or the Salesforce CRM system, you find out how much traffic typically happens, and you double it. Then you create an integration solution, which you benchmark to see whether it can handle that particular load. If it's going to be a cloud-based solution, you again do something similar, but at a much grander scale. That's when you put a load balancer in front and do all your scalability tricks.

One of the senior persons in Software AG is an old colleague of mine, a junior, so whenever I need webMethods Integration Server support, he'll pass me the name of the chief programmer over there, and I'll talk with him on the phone. In general, the software is good. The service quality is also good, and I don't remember any significant instance or problem I faced regarding support.

The complexity of setting up webMethods Integration Server, or any other enterprise integration solution, lies in the data you connect between two enterprise applications.

For example, you have to ask if you have to link ten SAP modules to two Salesforce CRM modules because that's where the complexity comes in. It's not the fault of the webMethods Integration Server if the initial setup is easy or difficult.

The business context would make the setup more complex, and an ESB tool, such as webMethods Integration Server, is just one piece of that puzzle.

Comparing webMethods Integration Server pricing with other solutions depends on the context. The cheapest will always be open-source ESB solutions, such as Apache ServiceMix and Apache Camel. Still, when you compare the quality of support of enterprise software, such as webMethods Integration Server, with open source software, enterprise software usually provides better support quality and higher level solutions versus open source software that typically doesn't have a real support model.

If you're lucky, you'll get someone who will immediately give you support for your open-source solution, but if not, you'll wait for months without any real support. webMethods Integration Server, on the other hand, as it's under Software AG and has an enterprise behind it, can create one-tier, two-tier, and three-tier support mechanisms, apart from providing you with timely support. Hence, you can use the product as part of an ongoing, much bigger integration project. That's where the differentiation and the value come in.

From an enterprise context, the price of webMethods Integration Server isn't that high because Software AG enters a relationship with companies and provides webMethods Integration Server as part of a much larger solution.

I've been in the IT industry for about thirty-two years now. In 1999 or 2000, a Dutch colleague and I created the entire concept of ESB (Enterprise Service Bus), so I have a long history in this particular space, and I've used all ESB products in the past. Right now, I'm the principal architect of a company that provides multiple solutions to financial institutions worldwide. I use ESBs, such as webMethods Integration Server, as part of the solution whenever there's a need.

webMethods Integration Server can be deployed either on-premises or on the cloud. The cloud is a big misnomer, as it's just a server elsewhere. As long as it's connected over a PCP software network, you can take advantage of it.

I'd tell anyone looking into using webMethods Integration Server to talk to the people in Software AG as the vendor has a portfolio of products. webMethods Integration Server is just one offering, so if you can get good value across a portfolio, go for it. However, you need to do the due diligence and create a pro and a con list for different software solutions available in the market. If you're rejecting open-source solutions, you need to have clear business reasons why. For example, maybe you need immediate support, your timeline is short, or your integration project requires a quick turnaround time. My organization is located in Germany, so it's much easier for it and the customers to work with Software AG and webMethods Integration Server, for example.

webMethods Integration Server is as good and bad as other enterprise products I previously worked with in Europe. No significant problems stood out, so my rating for the solution is seven out of ten.

One of the most important features is that it gives you the possibility to do low-level integration. It provides a lot of features out of the box, and over the years, it has matured so much that any problem that is there in the market can be solved with this product. We can meet any requirements through customizations, transformations, or the logic that needs to be put in. Some of the other products struggle in this aspect. They cannot do things in a certain way, or they have a product limitation, whereas, with webMethods, I have never faced this kind of problem. When clients come to me with any problem, in about 99% of cases, I say, "Yes, it is feasible to do through webMethods." It has reached such a level of flexibility and maturity. Most of the things are available out of the box, and even if something is not available out of the box, we can customize it and deliver it for a client's requirements.

Version control is not very easy. The packages and the integration server are on Eclipse IDE, but you can't compare the code from the IDE. For example, if you are working on Java code, doing version control and deployment for a quick comparison between the code isn't easy. Some tools or plug-ins are there, such as CrossVista, and you can also play with an SVN server where you have to place your package, and from there, you can check, but you have to do that as a separate exercise. You can't do it from the IDE or webMethods server. You can't just right-click and upload your service. CrossVista came up with a solution, which was with the upgraded version of webMethods, but even that was lagging. CrossVista was a bit delayed in coping with the new versions of webMethods. Many times, we get into a situation where we want to know who made a change, when it was made, and how it was before the change. When something that was working well previously suddenly stops working, we want to go back and see who made that change, but because of these version control restrictions, we have to take a longer path. We have to go to the version control system. There is no direct feature in webMethods for that.

There should be more visibility. Currently, Software AG has multiple tools. They have webMethods, and then they have Terracotta as a different product. They have an API governance tool as a different product. They also have Trading Networks. Some of the tools have a very good UI, and some of them don't. For example, earlier, there was a message broker, and you were able to visualize what is happening to a document on the server. You could plug in a broker and see everything. You could see the number of documents that are there on a broker. You could see different queues and topics created. They then moved to Universal Messaging, which is a nirvana-based universal messaging solution. Now, the plug-in is gone, and from the MWS server, you cannot see what is happening in UM. A different view is created for that in Enterprise Manager, which is a desktop UI application. It is not a browser-based application. So, sometimes to monitor different tools, you have to go to different screens. Everything can't be monitored centrally. If you have MWS, not everything is on MWS. Command Central is a different screen altogether. There should be a centralized UI on which every component can be plugged in so that it's easy to control, view, and monitor everything. That's what I really want to have. The Universal Messaging Enterprise Manager is especially very difficult. Sometimes, it takes time to launch on your desktop. It is basically a desktop application, and you need to have a powerful laptop or hardware to launch it. They should make it a browser-based solution.

Their support could also be improved. They could be more responsive and quicker.

I have been working with this solution for almost 12 years.

Its stability is very high. It is very stable, and I've never seen it crash. In my 12 years of career, there have been hardly one or two instances where there was an issue, but that was also because of some issue in the development where we had memory leakage.

Its scalability is good, but you have to plan it in advance. When you are designing your overall infrastructure architecture and delivery framework, you need to put scalability at the core of it. Once your infrastructure is set up, it's not very easy to scale it up or down.

Most of the time, admins interact with the support because they handle day-to-day installations or upgrades. I have had some experience with them. I don't have much experience. I hardly had one or two instances where I had to interact with them. It was not very smooth. It was okay. I ultimately managed to get support, but it was not very straightforward. The ticket lingers on for two days or three days, and there are multiple reassignments before it reaches the right party. Based on the little experience I have had, I would rate them a three out of five.

I have not got a chance to work a lot with other vendors. The first ESB I used was OpenESB, which is Glassfish-based. It was ultimately owned by Oracle when they acquired Sun. I used it back then. I also got a chance to work a bit on microservices and Apigee. Microservices are based on Spring Boot. So, it is a Java product. Apigee is an API governance tool. It is now a Google product. 

Apigee is a very good tool for API management, but a lot of scripting and coding skills are required. You need to be a genuine coder, and you should have an understanding of JavaScript, Python, or whatever else you are using to work with Apigee, whereas with webMethods API governance, even if you're working as a developer or designer for the integration server, you just need to know the basic concepts of programming. You do not need to know .NET, Java, etc. You just need to know about the integration. You should know how a web service works, how an API works, and how SFTP works. The tool itself is based on Java. It also uses Eclipse IDE. It has similarities with Java. If you feel that something is not achievable through what is provided out of the box or you want to do it in a slightly different or optimized way for your requirement, it gives you an option to write a Java service. There is an option to write Java code, but as the product is becoming mature, the requirement for a Java service is becoming very less. The product is evolving based on the learning of the user experience. It is evolving based on the problem statements and the scenarios where the product was not giving sufficient solutions. They kept including any missing functionalities in the new versions. That's why now the requirement to write a Java service is minimal. In a team of 100, if you have two Java resources, that is more than enough.

It depends on what role you are playing. Are you working as a developer or are you working as an admin? For a developer, it's very simple. It's not very complex. You just need an Eclipse-based designer IDE and a browser installed on your machine. That's all. You are all set. However, as an admin, you have to install and maintain all the components. You have to install the patches, and updating these versions is not very smooth. The update manager that they have provided is not very accurate. Sometimes, it fails. If it fails in between, it is very difficult to recover from that failure. So, from an admin's point of view, it is a bit difficult, but from a developer's point of view, there is nothing much.

We generally have webMethods Integration Server on-prem. We are deploying it on-prem, and there is a deployer, and there is also a webMethods IO component, which is more cloud-based. The VM on which it is installed could be hosted somewhere on the cloud, which is a different story, but the product itself doesn't have any cloud capability where you can directly put it on a cloud provider host.

I would rate it an eight out of ten.

We have a lot of use cases for this product. Initially, when we bought this product from Software AG, it was only for a specific project. But, we did watch for other opportunities where it could be used for integration and that's what happened.

Our business model has many verticals, so it's used across the enterprise. The main function is to provide application integration within the company. We have more than 60 applications and at the moment, it's talking to more than 30 applications and integrating them. In this context, it is used by our sales team and in a lot of automations.

Our second use case is to provide Write as a Service. We write any custom service using webMethods and then expose it to others as a REST service.

Another thing that we use this solution for is managed file transfers.

We have this solution deployed in a hybrid environment. It is available in our private cloud, where it is installed in AWS, and we also have it in our data center.

This solution has improved our productivity and efficiency in pretty much all of our applications. There are some currently-running automation projects where we are going to have to transform data and at the moment, it is being done manually. This is another case where we will implement webMethods to improve productivity.

We automate our sales cycle using API orchestrations. When sales come through, for example, we register them and enroll them in the policy. All of this is done within webMethods and it works well.

With respect to the comprehensiveness and depth of connectors that are available, they have a lot of traditional ones available. They are constantly adding new ones, which is good to see. However, what we found is that we can develop them very easily. Nowadays, pretty much everything is REST so it is easy to develop your own. We do not have a license for many of the connectors. One of them that we have is Salesforce, which was what we had originally envisioned.

Then, what happened when we needed another connector is that we reasoned that rather than buying additional ones, we would instead create our own. Ultimately, we found that it was quite easy to do and in my experience, it is always better to use your own because the out-of-the-box connections have limitations. This is what we found with the connector for SuccessFactors; we were better off building our own because there are no constraints when we do it that way.

This solution encompasses a range of features, which is important to us. We use it heavily for application integration and APIs, somewhat less for data integration, business to business communication, and we are trialing microservices. Although we do not yet heavily use the microservices feature, we do like that it provides it.

We plan to expand our usage of microservices because, in the AWS world, we want to make things auto-scalable. This is what we are playing around with and although we do not yet have it in production, the plan is to use it more.

Modifying and redeploying integrations is easy to do. This has made us more agile and the fact that we can churn things quicker has helped the business.

There are a few things about this product that we definitely like. It is very robust. If you build it nicely, you can't go wrong with it. It's rock solid.

The development is very fast. If you know what you're doing, you can develop something very easily and very fast.

For the latest services, the product is lacking in terms of connectors. For example, there are a lot of SaaS providers and if you look for the connectors out-of-the-box, they are definitely not going to be there. They have a lot of traditional options but they are basic. If you have an advanced use case then you are better to build your own.

For the most part, this solution supports the latest standards and makes it possible to plug in modern tooling and third-party products for automation and innovation. However, there are some things that it doesn't support and we find ourselves having to wait for a newer version. For example, when we were using version 9.10, it did not support OAuth.

In general, I would like to see the vendor release newer features sooner. Or, it would be helpful if we can use a newer feature but don't have to upgrade the entire product.

The UI for the admin console is very old. It hasn't been updated for years and is pretty much the same one that we started with. This is something that could be refreshed and made more modern.

We have been using the webMethods Integration Server for almost six years.

I would rate the stability very high. Once it is running, it's very stable.

The webMethods Integration Server is a tier-one application and if it's down, impacts pretty much everything. When it runs, no one knows about it but if it goes down, everyone screams. It is very crucial.

With our current licensing, it's very easy for us to scale. With our older licensing model, it was very hard. This is definitely something that I would highlight. I'm very happy with our current setup because we can scale and it's more of a constraint of your commercials rather than a product constraint when it comes to scalability.

We purchased a premium support package but to this point, we have not greatly depended upon it. In our day-to-day business, we haven't had to deal with them very often, which is a good thing. We generally resolve things within our team and don't generally need to rely on others. There are only a few issues that we have contacted technical support about, such as when we were having issues with the upgrade. Also, if there is something that we can't find then we will contact them.

In general, when I compare their support with other vendors, I would not rate them high. The customer experience with support is an area that needs improvement. The reason I say this is that regardless of the issue you raise, even if it is not necessary, they ask a lot of questions.  

Prior to webMethods, we were not using an integration solution. We were a .NET shop and we were using it to accomplish the same tasks. However, it was not to the full extent that webMethods is doing because its capabilities are less.

The reason we adopted webMethods is that a new project was coming and when we estimated the cost, we found that developing everything in .NET was cumbersome. At that point, we started to look for a tool and settled on webMethods.

We chose webMethods over MuleSoft because of how quick and easy it is for developing. It is simple and easy to use. The commercials is definitely another reason that we chose it. This was the product that was recommended after the technical evaluation was complete.

We also use webMethods.io, although that does not fall under Integration Server.

The initial setup is of medium complexity, although it depends on your scenario. If you have a simple use case to just integrate, it's easy. The actual installation is very straightforward but we had some complexity because of the zones.

We had multiple DMZ zones and we have a PCI zone. This meant that there were a lot of firewall rules that needed to be created. It was a greenfield project, so we had to build everything in addition to the webMethods aspect. The project was definitely complex. However, the webMethods setup in isolation was very straightforward. If you just focused on, "Okay, this is the one that you have to install." It's straightforward. If you know what you're doing, it's easy.

Upgrading is something that we can't do in a very fast manner. It's not like we are going to upgrade every six months. We have to wait a while. On the other hand, that's where the microservices architecture is good because anytime something new is released, we can upgrade to the latest.

We completed the initial setup in-house.

We evaluated MuleSoft and webMethods. There may have been others but these were the top choices. When we asked for demonstrations, these were the products that we looked at.

This product provides us with a single hybrid-integration platform for all of our integration needs. We do have another product but it is for a very specific use case, and it is separate because of the licensing. Otherwise, webMethods is our go-to for integration.

On the topic of development time, this product can save you time but it depends on what you're comparing it to. For example, if you are comparing it to having no platform, where all of the integrations have to be developed from scratch, then this product will definitely save you a lot of time. The undertaking would be massive. If instead, you are comparing it to another product such as MultSoft, then it will be a different answer. It is tricky to estimate because it depends on the tool.

This is a product that the vendor keeps adding things to. Sometimes, we have to wait until the next version comes out before there is support for what we want to do, but there hasn't been anything major.

My advice for anyone who is implementing this solution is to spend some time thinking about how it will be used. I have seen instances where the product was being used and didn't work properly. If it is designed nicely then it will work wonders, so spend some time thinking about the design and how it will be used and it's never going to have any issues.

I would rate this solution a nine out of ten.