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

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.

Deploying is something we have found to be lacking with native webMethods tools, as is the ability to plug into a change management system, so we built our own deployment system. But again, we built it with webMethods' foundation tools and then interfaced with sub-version, version control, and our own home-built change management system. We used it to enforce that things can't go to prod unless they pass the QA stage and have had successful QA acceptance testing.

It would be nice if they had a change management system offering. We built our own deployer application because the one built into webMethods couldn't enforce change management rules. Integration into a change management system, along with the version control system, would be a good offering; it's something that they're lacking.

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.

We would like to achieve a multi-site, soft data center. Multi-site meaning that we would like to have more than two Active-Active data centers because Indonesia is a big region with three time zones. We would like to have many data centers serve us across the islands to support the massive number of transactions. We need to have a good amount of availability. Hence, we would like to have a multi-site data center. To support that, the solution needs to be capable of Active-Active implementations, an Active-Active integration server. We would like to get to the point where transactions are not only coming into one data center but, simultaneously, could be redirected to several other data center sites. Integration Server needs the capabilities to help us to achieve that goal.

Also, the solution has big instances when deployed under microservices or in a containerized platform. They need to improve that so that it is competitive with other integration solutions, like Redis and Kafka. Deployments under microservices with those solutions are much more lightweight, in the size of the runtime itself, compared with Software AG. They need to improve it to be scalable enough and lightweight enough to run on the microservices/containerized platform.

We are paying them a lot so we have access to their product development engineers. We are waiting for them to revamp the microservices areas. We are waiting for the new version of that. They have come back to us with something that is much more lightweight, but to us, it has still not reached the lightweight level that we want.

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

The solution can be buggy. If I compare it with IBM, before webMethods, we were using IBM DataPower. To be frank, DataPower had very, very minimal bugs. You may have one or two bugs in maybe a year, whereas with Integration Server, with customizations, it comes with all these caveats. We had to go back to support a bit for help.

Support is expensive. 

There is not any capability as a managed service. Maybe a managed service would help people to use it. Or apart from that, I would also say there is a containerized microservices version, yet it is not in a usable format. If you look at a Kubernetes environment, if you want to have a containerized application running in Integration Server, it's still quite very heavy. Maybe webMethods should look at that perspective as well to run a pure proper cloud-native environment. If you look at Spring Boot or maybe a similar open-source application, you can easily containerize and run Kubernetes. In Integration Server, it's not very easy.

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.

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. 

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.

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.

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.

Other products have been using AI and cloud enhancements, but webMethods Integration Server is still lagging in that key area. It's very good as a standalone integration server, but it has to come up with more features in the cloud.

The solution's API management is slightly lagging, and its API policies could be improved.

webMethods Integration Server could improve on the version control. I'm not sure if Web Method has some kind of inbuilt integration with Bitbucket or GitHub or some kind of version control system. However, that's one area where they can improve. 

The migration of the code between environments could be better. If they come up with some kind of a continuous integration process to promote the code from one life cycle to the other, that may ease the day-to-day activity for us.

I'd like to see the admin portal for managing the integration server go up a level, to have more capabilities and to have a more modern web interface.

We're fine with the product offering.

It is quite expensive. 

I would like to see the price improve.

As webMethods Integration Server is expensive, that's its area for improvement.

On the monitoring side of things, the UI for monitoring could be improved. It's a bit cumbersome to work with.

There should be better logging, or a better dashboard, to allow you to see see the logs of the services. 

Also, storing the message bodies in the database and allow you to search them would be a nice feature to have.

These features should be enhanced to facilitate the work for the developer.

For code version control, you need to use some external software. It would be good to have it just built into the product so that you don't have to use anything external.

The interface could be modernized. 

A while ago, they were hacked, and it took them a very long time to open their website again in order to download any service packs or any features. I don't know what they could do differently. I know that they were vulnerable, and there was some downtime, but because they were down, we were unable to download any potential service packs.

This solution could be improved by offering subscription based licensing.

The logging capability has room for improvement. That way, we could keep a history of all the transactions. It would be helpful to be able to get to that without having to build a standalone solution to do so.

We would like to have a gateway server included, where we can control the number of requests.

There is an interface in webMethods for building a portal, but we are not using it because the price of the license is too high.

I would like to have a dashboard where I can see all of the communication between components and the configuration. As it is now, it is a lengthy search process. When a request comes in, sometimes you have to go to the administration page and then search the web after that. I need to be able to trace the flow from the port to the service to find the issue and there is no diagram to show me the parts. This is something that would be helpful.

Programming model with flow is hopelessly outdated. Forced migration from MessageBroker to Universal Messaging requires large scale reimplementation for JMS

webMethods Integration Server needs to add more adapters. 

I think they need to improve the API gateway to be able to replace F5 for example. Also, handling the certificates and their implications with other applications needs some improvement.

We need more dashboards and reporting engines that can provide detailed information for management. In short, we need better analytics.

• DevOps support
• Java services debugging.

The Java Service section, which is probably needs more different manners for a new developer. It doesn't represent OOP very well, just a method and proprietary interface for input parameter called IData, which consists of Maps (key, value). You can still be creating classes under the shared section of the methods. But also the documentation of webMethods Java API it doesn't cover much clarity for the usage

The newest version, which we are not on, has all the features that we are looking for, meaning managed files transfer adapter.

Documentation needs tuning. There is a lot of dependency with SoftwareAG. Even with the documentation at hand, you can struggle to implement scenarios without SAG’s help. By contrast, IBM’s documentation is self-explanatory, in my opinion.

The product must improve the performance of Designer. The product must add more compatible connectors. The solution should provide more customization options.

The solution could be more user-friendly. They should include proper documentation for easy understanding.

We'd like for them to open up to a more cloud-based solution that could offer more flexibility and maybe a better rules engine or more integration with rules engines. The rules should also be more centralized. 

We'd like to see more documentation. We feel like we may be missing some things and would like some documentation to lay out the entire product better. We need better use cases. They don't offer many examples to showcase their product's capabilities. 

When migration happens from the one release to an upgraded release from Software AG, many of the existing services are deprecated and developers have to put in effort testing and redeveloping some of the services. It would be better that upgrade releases took care to support the lower-level versions of webMethods.

This is a great solution and the vendor could improve the marketing of the solution to be able to reach more clients.

We have been experiencing problems with using Terracotta for clustering, which is something that they should improve.

Technical support is an area where they can improve.

The development tools need to be improved. They aren't very effective for us to use as the requirement to use the Software AG Designer is quite big. Sometimes our developer doesn't have a really high-end spec laptop or desktop computer. They sometimes have trouble opening the Software AG Designer to develop something.

The Software AG Designer could be more memory-efficient or CPU-efficient so that we can use it with middle-spec hardware. That would be a great improvement for us in development.

For a new user, the initial setup is hard. 

The quality of the message queuing could be improved. In webMethods they have something called Universal Messaging. Future modules could be included in the Integration Server for different queuing. Currently, they have the basic queuing for messaging. Maybe in the future, they can have built-in different priority queuing to make it a lot faster.

I must be blunt. The solution is really hard to use, as the manual and documentation fail to provide proper explanations, especially to people who are first time users of webMethods, Software AG. I struggle with the installation. I sometimes think that the Integration Server is fine and that I had no problem with the API gateway, only to find myself having to redo this, as I lack a dedicated person who can instruct us on installation. I must rely on the Software AG forum. 

The installation process should be simplified for first time users and be made more user-friendly. 

The product needs to be improved in a few ways. First, they need to stabilize the components of the whole platform across versions. Also, they should stop replacing old components with brand new ones and, rather, improve by evolution.

Need to see more API portal features like monetizing APIs and private cloud readiness.

At least in SAG Webmethods 8 there was no Data Value Repository tool that would allow to map values/codes from source (in our case HR portal) and transform that into target ERP codes (SAP and PeopleSoft)

We therefore had to create our own solution and make calls at runtime to that repository (we called it Value List Repository or VLR for short) to resolve correct values in target.

The tool has its own proprietary language. It does not use Java or C#. The learning curve is a little steep at first. Once we get familiar with it, we might like to use it. The product must provide AI features to auto-generate logic based on our request.

We have been having some non-technical, functional issues, which is why we're exploring other products.

The price should be reduced to make it more affordable.

The Flow language mapping tool could be a little easier to use. The interface needs improvement.

The stability of the various modules of the product suite have been a bit of a concern lately. Though their support team is always easy to reach out to, I would prefer it not come to that.

Business monitoring (BAM) needs improvement because the analytics and prediction module very often has performance problems.

Additionally, this product has too many gaps. You find them after update installations. This should be covered by automatic testing.

Mostly, an improvement is needed in the product's documentation.

The documentation deficiencies were in the following areas; since it has been a while, I could recall the top instances where the escalation reached to my level.

wM SAP Adapter User Guide - Example, like Message Broker setup was unclear, leading to issues during Testing and we had refer the internet forums to understand that there is a Message Broker Cleanup utility and that needs to be setup as well.

Release Notes: Used to cover only the latest update for the SAP changes. What has been done to the older version (SAP R/3 4.6, etc.) were not mentioned.

Rapid application development has to be considered, especially for UI, where user interference is crucial.

• Broker
• Trading partners
• Portal

Large file handling is pretty hard comparatively to other middleware tools. 

The installation process is very complex, there being many products, each having its own. The deployment should be simplified. 

Software AG should investigate the reporting of products like Spotfire from TIBCO.