webMethods.io Reviews

This solution is primarily used for protecting our APIs and web services. All of our APIs are exposed to the outside world, so our internal network is protected by the API gateway. Our landscape inside the company is also divided into different domains and if you go from one domain to another domain, we also want the APIs to be protected.

We have two servers with an API gateway and a load balancer in front of it.

We also use this solution for monitoring, to know how many transactions we have had and who is using our API. These are the runtime capabilities.

Another thing we use this product for is governance, to govern the lifecycle of our API services. It will tell us the state of the service, who is responsible for it, and what deliverables belong to that stage, and we also have some quality checkpoints inside the lifecycle.

With respect to the end-to-end lifecycle management of APIs, this product is very good, feature-wise. We have the ability to govern the end-to-end lifecycle; in the different states, we can do the necessary customization and add our own flavor. This helps us maintain it very well.

The API governance capabilities for enforcing standards and security policies are quite good. However, it is a new product that started a few years ago, and you can sometimes tell that it is new and still evolving. For example, there are some bugs and problems that are still being fixed as it is further developed. They are evolving the features and we are happy with the product, but there can be more issues that arise as things change.

These quality checkpoints allow us to have a central team that reviews the deliverables of the service. In the Design phase, for instance, we will review the REST API interface to see if it matches our standards.

This solution has enabled us to create new channels for growth because we can quickly introduce new APIs. Sometimes, you need to quickly set up a marketing campaign with an application that needs to happen fast. The API gateway allows us to introduce APIs that are still good and protected but in a fast way.

We have a good overview of all of our APIs, including who is providing them and who consuming them, which allows us to better work together to resolve issues before they emerge. For example, if there are changes made, we have a better view of the impact and the team can start discussing it. Also, if we are deprecating services and removing them, we know who is using these APIs and they can be contacted in advance.

Another important point is that when a new application wants to use an API, it can provide the necessary information such as the number of transactions. With this knowledge, the provider can adapt accordingly and it will be possible to add it.

Using the product has provided us with a structured API management program. Because we have governance and knowledge about all of the APIs, we have a better overview. Knowing who is using an API, or who is going to use it, means that it is easier to introduce new things.

This solution has given us a competitive advantage because we have better automation and insight. Without it, a lot of automation would not be possible, and doing it manually would take more time.

More generally, this API gateway has improved the way our organization functions because it allows us to enable more partner integrations. Until now, most of our business-to-business integrations were going over EDI. With API instead, it will allow us to onboard other partners. The reason for this is that EDI is a very heavy format, which is very expensive. As a retail company, EDI is affordable when you have a large vendor. But sometimes we have smaller vendors, and if we force them to use EDI, it will sometimes block the ability to sell products to us because they can't afford the complete functionality of sending invoices or receiving orders.

What we are now doing with API management is to make the order and invoicing systems available via API. These smaller vendors can then use these APIs to send an invoice or to receive an order.

The two most important features are the lifecycle and the protection of your APIs.

On the topic of protecting your APIs, every API management solution has that, which is the core business. Without it, you don't have an API gateway and it's the basic setup that every API management solution needs. Of course, protecting your APIs is very important.

With respect to the lifecycle, it is helpful because, in our business, we find it important to have an overview of all of our APIs and to guide our different roles, including architects and solution developers, in the necessary work for delivering a web service. Depending on the type of service, we also want to govern the quality. We don't do it for all APIs but for some categories, we find it very important that the quality is at a high level. This means that we want to govern that and review it.

In these aspects, this solution helps us.

In relation to the lifecycle features, the user interface and the performance can be improved. It is not the quickest application and the user interface is not the most up-to-date. It's a tool that has existed for quite some time, and there haven't been a lot of improvements.

With respect to the API gateway, the runtime component, and the stability after a new release is something that can be improved.

I have been working with the webMethods API Gateway for approximately five years.

Once the system is set up and configured properly, it's stable. We don't have outages and it runs very well.

There are two ways to scale this product, and both of them are easy to do. The first is to add another server to your cluster, and the second way is to add more CPU power.

I would rate the technical support medium-high. It is comparable with other companies; not worse, but not especially better.

In general, I am happy with the support but my complaints are about the timing. Specifically, if your issue can be handled by the first line then you get feedback quickly. However, if the issue is complex then it needs to go to R&D and it takes time. This is the same experience that I have with other companies.

Positive

We did not use another similar solution prior to this one.

The installation and initial setup are complex. It is not possible to just keep clicking the Next button during the setup. You need to configure the system such that it works best for your environment. You should plan for deployment over three to six months, at least.

My advice is to involve a consultant from Software AG to help you with the setup. Of course, this is an on-premises situation. In the cloud, I don't know how easy or difficult it is.

We have seen ROI from this product and we are able to determine this because of our internal accounting. When a project starts, we always calculate what our benefits are with respect to the technology. Taking into account the number of web services and APIs that we have, we're pretty sure that considering the cost of governance, this solution is better than if we were not using one.

This is not a cheap solution but, compared to other products such as those offered by IBM, the pricing is similar.

We did evaluate other options including IBM API Connect and Apigee. Feature-wise, these products are comparable.

Given that we were already using webMethods, using the API gateway had some benefits. There is value in staying with a single vendor, with the advantage that it is easier to integrate with other products in the webMethods stack.

We did not consider using any open-source alternatives.

This solution provides a fully customizable portal that has built-in testing capabilities, although we haven't implemented it yet. This is something that we are planning to do within the next couple of months.

My advice for anybody who is implementing this product is to involve consultants who are familiar with it because they can help you to best set it up. Also, think about the process and steps in your governance because this is a workflow and you want to be sure that it follows the procedures that you have in place.

Overall, I'm happy with the product.

I would rate this solution an eight out of ten.

Most of our applications are business applications we support, customer lookups, and what methods provide those services that have calls to our apps that needed that infrastructure. We are a combination of of Rantor Docker web methods. 

It allows us to to reuse services, meaning, you know, App Bay would have a customer lookup service Appbeat could reuse that service.

The messaging part is the most valuable feature. 

The patching of infrastructure is not very smooth and improved authentication should be added in the next feature. 

I have been using webMethods Integration Server for fifteen years.

The solution is highly stable. I rate the stability a nine out of ten. 

I would rate the scalability an eight out of ten. 

I have seen a Return on Investment. 

It is a cost-effective solution. 

Follow best practices,engage in their professional services to help build your  messaging system and to be PR have some PR emphasis and and blue Bluegreen deployment You could take half your your clusters out, upgrade them, and put them back in so you have a quick callback.  And also patch quarterly, we got we got downbound. And and at that point, it's a little hard to get into the cycle when you're releasing software every every week, and you're trying to, go through an upgrade seven fifty servers, it's a little hard to get into the upgrade flow when when you're running that tight. 

I rate the overall solution an eight out of ten. 

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. 

I have used webMethods Integration Server in a variety of roles over the past eight years, starting as a developer and progressing to integration specialist where my work entailed building enterprise solutions to process a lot of data (millions of records each day) using event-driven architecture.

Our primary use case is retail integration where there are a lot of orders being placed daily, and where all the inventory needs to be updated in the centralized system. It's mainly in the retail and banking sectors, or anywhere transactions may play a crucial role, where I have used webMethods the most in my projects.

Typically, it is used where data has to be going to multiple systems on-the-fly, such that there will be minimal latency. For example, in an event-driven process where there is an action trigger for a piece of data or record to be forwarded to multiple systems when that action has been triggered.

The latest versions I have worked with include 10.5 and 10.3, however at the moment and for the past year I have been working with MuleSoft more than webMethods.

Our infrastructure is mainly on-premises, but we are starting to move to the cloud. Our target is to move everything to cloud, and right now we have a few instances on-premises and a few in the cloud, hosted privately with Microsoft Azure.

As for users, we are not directly exposed to the clients or end-users. Instead, we are mainly part of the middleware layer, whereas many of our customer-facing portals are different and distinct from one another. If we counted from one portal, the users may go into the thousands or even billions sometimes. It depends on the transaction type that is involved. For example, if you take any store of the multiple stores in operation, we will get a daily number of orders and that number of transactions will go through our system. Ultimately, it differs from region to region and client to client, but the numbers on any store can be from thousands to 10,000 or more.

One valuable feature is that it is event-driven, so when new data is available on the source it can be quickly processed and displayed. Integration is definitely another useful feature, and B2B is one area where webMethods has its own unique thing going, whereby we can do monitoring of transactions, monitoring of client onboarding, and so on.

There are many valuable things from an EDA perspective, and webMethods helpfully supports a lot of formats. Considering their market strategies, I think webMethods has it all. And now there is webMethods.io, which is a complete cloud-based solution provider. Unfortunately, they are mainly known in the market for their broker transactions, and this is a perception I believe needs to be overcome.

Lastly, although I'm not too sure about the latest features, I believe they also have a service designer now, where you can work out the particular package that you want. 

The certifications and learning resources are not exposed openly enough. For instance, they have a trial version which comes with only a few basic features, and I think that community-wise they need to offer more free or open spaces where developers can feel encouraged to experiment. Perhaps they can work on maintaining more of a community in order to build up a better knowledge base, which is exposed on the free plans and not tagged to a particular paid version.

Otherwise, I think they have already built all the solutions as an individual component, so what they have currently should be fine. Based on the market, the new features should come up as usual, and I hope to see a lot of connectors become available with regard to NoSQL databases, Salesforce, CRM systems, and so on. And with these, I mean plug-and-play types of connectors, where we can easily experiment and see which products work well in the integration scheme, and which will help us decide whether to go with webMethods or not.

I've been using webMethods Integration Server for over eight years.

Compared to on-premises, the cloud solution is not as stable. These days I see a lot of network issues and cloud servers going down, becoming unreachable for whatever reason.

The cloud plays a major role in its scalability. When it comes to on-premise, it's not that scalable, as you will need to have a server and a standard process around that which will reduce the delay. In general, it's not that easy to get a system scalable when it is on-premise, especially when compared with the cloud as it's much easier to scale a system horizontally or vertically with any number of resources.

Their support is always good. We used to have regular meetings with the vendor where they explained things and gave details about new features and products that are going to be launched down the line. And if there are any product bugs, we align with their support to get things sorted out. We have a good relationship and approach with the vendor, who adheres to their SLAs.

The initial setup was more of an administrator task, so I did not participate in it directly. However, as far as I know, the software that comes with the installer is a complete package so we just needed to install it. It does require a bit of information which needs to be addressed prior to getting installed, though.

When it comes to code deployment, the code and packages that we work on go through the servers with CI/CD pipelines.

We do our implementations in-house only, with the help of automation. The number of engineers needed depends on the requirements for each project. At this moment, there is one person who takes care of the automation and troubleshooting of issues because it's all centralized and we don't have a dedicated team to do the deployments.

As we are all into different sectors, we typically release with all the teams together, and the release window doesn't account only for the team or the tools we're using, but it is also dependent on the complete functionality desired. So when there is a deployment planned with other teams, everyone has to release their code and do a round of testing, and then validate if everything works properly. It has multiple verifications and if something goes down then we have to report it. As such, I don't give timelines because it depends on the release, but typically webMethods' package deployment doesn't take that much time unless there are network issues.

I am not involved in the licensing side of things.

Whether you decide to use webMethods largely depends on the architectural landscape that the customer is looking at, and in particular what kind of flow data they want to process. It's always a matter of first getting the customer requirements, and then going with the tool that is easiest to implement and use.

Overall, I would rate webMethods Integration Server a seven 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.

webMethods.io was used to integrate APIs through the webMethods.io platform, trigger database events, and connect backend APIs through a Java backend. It was used extensively for integration purposes in my organization.

Integration became smoother, troubleshooting was easier, and deployment and scalability were greatly enhanced.

The orchestration aspects of APIs, the integration capabilities, and the logging functionalities were the most critical features of our workflow.

The licensing cost is high compared to other options. Additionally, AI support could be improved. Overall, the features are good, but the high cost could be a limiting factor.

I have worked with the solution for around three years, including approximately one and a half years in my previous organization.

Stability was rated as eight out of ten. We found it quite stable in operation.

Scalability was quite good; I would rate it an eight out of ten.

Customer support was generally good but some issues took time to resolve. I would rate it a seven out of ten.

Neutral

Before webMethods.io, other third-party solutions were used. webMethods.io was chosen because of its smooth integration, scalability, and good support.

The initial setup was straightforward, both on-premises and later on the AWS cloud.

A third-party integrator was used to deploy webMethods.io. They provided the necessary scripting and guidelines for the deployment.

I'd rate the solution eight 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. 

Our primary use case for webMethods Integration Server is for our internal application integration. We use it to expose REST and SOAP web services and to connect it with SAP.

We also use it as a bridge to transform web service calls. We'll use an ESB if we want to transform the protocol or the message. It's also used to connect our internal custom-written Java applications with products like SAP, which don't have an open standards interface.

We only use it on-premise. We are considering going to a hybrid setup but at the moment, we don't have it yet. Nevertheless, we still use the Integration Server to integrate our cloud applications. We only have cloud on-premise integrations and not cloud-to-cloud. That is also why we're not focusing on a hybrid setup.

Integration Server does our business-to-business integrations. It does all of our EDI integrations of passing over our Integration Server and our LAN connects to our internal applications.

Its adapters and connectors provide the fastest way to build an integration. We don't need to create our own implementations because we can use the adapters. We can immediately connect to the backend systems without creating a lot of our own custom code by using these adapters.

The vendor's full support for Integration Server's adapters and connectors brings long-term stability to our services because if something changes to the backend application, we don't need to bother with it. Software AG just adapts the adapter and we get a new version. It's much easier working this way.

Deploying a new application is rather easy. You need a deployer and to build a system. We have built something around it to add it to our continuous integration pipeline, but we have the necessary tools to test our production environments.

We use the same system to modify or redeploy these integrations. If we have a bug we'll adapt our codes and deploy a new version. The code changes need the most time. If it's a small code change, then it goes very quickly. If it's an important bug, it'll take more time. The deployment and build don't take a lot of time.

It's a visual tool, so our transformations can be quickly implemented without a lot of fuss. The fact that we have an easy way to expose REST services is also very interesting. It offers the possibility to connect over GMS to synchronize message brokers.

Using an adapter is quite easy. For example, the SAP adapter works very well, and connecting to custom applications is very easy.

We would use MQTT when we need to connect to IoT devices. For the other legacy apps, in most cases, we use the adapters. Acquiring an adapter is quite easy.

Integration Server provides us with application integration, data integration, business-to-business communications, APIs, and microservices. Internally we don't use it for data integration, but it is possible. We don't work with microservices but I know that it's also possible.

It is important to us that Integration Server offers us a broad range of features like application, data integration, and API. It's important to have that kind of broad setup because it's a service burst. It's in the middle of a lot of integrations. It has to be able to have a lot of features

In terms of improvement, it would be better if it adapted quicker to open standards. It took a while for API specification before the last version was available. The spec of version two was rather quick. 

With an integration platform, it sometimes needs to happen faster because you sometimes have clients or providers that already use new specifications.

I have been using webMethods Integration Server since 2011. 

I am very satisfied with stability. It's very stable, we haven't had any issues at all.

We had a lot of issues with our other solution but none with Integration Server.

There are many scalability options, it is possible to add core CPUs to your server or you can add additional servers. Both are possible, both are not complex. The only thing that you need to take into account is then the licensing, but there are no technical issues for scalability.

Technical support is okay. It's comparable with other companies. It of course depends on the kind of issue that you have, but I'm rather satisfied with their support.

We were using IBM before webMethods. We used a combination of the two. When we started we had both webMethods Integration Server only for B2B. We used WebSphere Enterprise Service Bus for internal application integration. It's easier to have only one. That is the reason that we chose one of both. The second reason was also that IBM was deprecating their product and asking to switch to another one. Instead of going through IBM, we figured we could do everything with webMethods which is why we completely switched over.

webMethods had a very good overview of all transactions. That was the main reason we went with them.

The initial setup was of medium complexity. It's new so you need to learn it. A tool like this is never easy. webMethods Integration Server was easier than a different solution that we were using. But it's not a walk in the park. You need to spend time on it. There are configuration settings that can't be avoided. It's a complex feature set. We have had more complex systems also in our landscape. It's not just "click, click, click, done."

I was not involved in the initial deployment. But I know that they upgraded to webMethods Integration Server in a month. It took a few months to learn everything in the system.

We worked with a consultant for the deployment. We worked with a consultant from Software AG which went well. We have also worked with other consultants from consultancy companies that were not directly linked to Software AG but work with a lot of Software AG products. They helped us to set up our webMethods products.

I don't think webMethods is the cheapest but I think the quality is worth it. But it's not cheap.

We're satisfied with our choice and the price is not a reason to look for something else.

It's wise to work with a consultant when you introduce Integration Server because you need to learn about the product. It's better to have advice from someone who already has experience with it.

I would rate webMethods Integration Server an eight out of ten. I'm quite happy and satisfied with it but nothing is perfect.