webMethods.io lacks advanced monitoring and analytics capabilities, so my customers need to use something additional.

Regarding the aspect of monitoring and analytics in webMethods.io, I wouldn't say it needs improvement; it was made for webMethods.io components, processes, and integration points. However, it cannot integrate with external services such as Apigee from Google for monitoring those web services in webMethods.io. You can monitor the calls between you and Apigee, but not the other calls to Apigee. Other platforms exist solely for these purposes, providing overall monitoring of applications and processes used by NOC departments.

In terms of areas in webMethods.io I would want to see improved in future releases, I think mainly the performance would be a focus, but the features already cover most if not all needs of integration. I've noticed components made to integrate with SAP and Oracle, but new applications in the market, such as ServiceNow, are booming. It would be good to have a separate component to cover integration and functionality for ServiceNow. Another enhancement would be in OCR; currently, there is a huge demand for OCR capabilities. It would be perfect if webMethods.io had a built-in component for OCR, as this would be tested and allow customers to use it better than a third-party OCR application. Having such a feature is essentially basic in modern applications.

Prices should be reduced, ideally by up to 30% for long-term customers like us. We have been with Software AG and now IBM for a long time, over 25 years. A special discount of at least 50% for old customers would allow us to expand our services and request more resources.

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.

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

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. 

As it is a mature product, I don't see the need for a lot of improvements.

The solution is increasing and bringing more and more areas of compliance into the picture. I think the tool is compliant to meet the standards, especially in terms of, health compliance, fintech compliance, or PCI compliance system by enterprise or API compliant. In the area of compliance, the tool is improving and getting more accelerators. The tool has been improving a few things, and making it better. I think that webMethods API Gateway is getting acquired by IBM.

I don't see any challenges attached to the product. Lately, webMethods API Gateway got introduced as a separate product. Initially, there was a more web service approach, after which webMethods API Gateway moved to the REST approach to meet the industry standards, providing the product more flexibility.

The high price of the product is an area of concern where improvements are required.

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 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.

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.

The main reason my company decided to replace webMethods.io Integration is because of the integration capabilities in the newer versions of the tool. Whenever there is a new version of webMethods.io Integrations, there is a lot of work to be done by our company since the newer versions don't offer seamless integration. The aforementioned reason can be considered for improvement in webMethods.io Integrations.

With the solution, our company has experienced sudden outages at times. The product's stability is an area of concern where improvements are required.

Not just the cost related to licensing but also the cost of introducing new versions need improvement in the product. When you have an OS like Windows or Apple, in which some new features are installed when you restart your system, after which everything works fine, with webMethods.io Integration, the new features introduced in the tool don't just need you to stop and restart your application but expects you to update the whole application to be able to use the new functionalities, which is something that is good. My company does a business in which we have to create a complete project which costs a lot of money. In the future, I expect to not be paying a lot of money or extra work to be able to update the product, and webMethods.io Integration needs to update the product automatically.

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.

One area for improvement in webMethods API Gateway is orchestration. Currently, API Gateway lacks built-in orchestration capabilities, so organizations may need to rely on other applications for this purpose. For example, if you are calling two services and one of them fails, you may need another application to handle the rollback or recovery process. Improving orchestration within API Gateway could simplify complex service interactions.

The improvement needed is related to the model's position. As of now, it seems to be more of a conceptual idea rather than a widely implemented solution. Monetization is currently on the rise, driven by the growing demand for APIs. With everything being provided as APIs nowadays, it's crucial to grasp this concept and establish a robust solution for subscription plans and the price model.

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.

The product should provide more customization options. Application of policy management is not easy. We have to do a lot of customization and configuration. Documentation is also a problem. Understanding the overall architecture is difficult.

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

The gateway server itself can improve the message queue implementation by considering the top ten web security controls.

I would like to request the integration of response caching into the memory database, which would eliminate the need to construct logic within the API itself, and instead implement it directly in the gateway.

The price has room for improvement.

There are things that could be improved with the webMethods API gateway. One thing is that it's too attached to the integration service and we'd like it to be a little bit more independent. We would like for them to separate operations so that it doesn't rely on the bulky integration server and so that it can be used everywhere. I would like for this to be included in the features since the client I work with always tends to avoid the solution. And if the client does not have existing interfaces with it, they choose not to proceed. 

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. 

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.

Any solution needs continuous development in integration and processing.

Some things could be improved, especially how ActiveTransfer handles third-party file transfers. It would be nice to have a native file-watching mechanism for when you're scheduling jobs with a third-party scheduler. 

Currently, we are using an outside file watcher solution to check the files before the file transfer. It checks the location to see if the file is there. If the file is there, it will prepare it for transfer. If the file isn't available, it will send an email it can create a ticket send it now. We recommended adding this file watcher mechanism. 

Also, when we're dealing with massive files, ActiveTransfer requires huge amounts of RAM, but if would be helpful if we could customize the compression and encryption to squeeze that data and reduce the size to save on system resources.

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.

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.

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.

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.

webMethods.io needs to incorporate ChatGPT to enhance user experience. It can offer a customized user experience. 

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.io Integration's installation is complex. It should also improve integration and connectors. 

The solution's release management and JSON services need improvement.

We're fine with the product offering.

It is quite expensive. 

I would like the solution to provide bi-weekly updates.

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.

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.

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.

I would like to see the price improve.

In terms of improvements, maybe on the API monetization side, having users able to create separate API consumption plans and to be able to throttle API execution against those consumption plans at run time could be better. Those are abilities that might need some improvement.

The on-premises setup can get a little complex, needs to be more simplified.

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.

Previously, we had some difficulties with end-to-end lifecycle management of APIs because the product was not yet mature enough. Two years ago, it was not yet mature in terms of the capabilities, which were still separated and not yet consolidated. There were several modules of webMethods API Gateway which needed to be consolidated into one webMethods API Gateway. Previously, they had two separate modules for API management as well as others. 

One of the improvements that need to be added into future releases is the ability to support other third-party monitoring tools. I know that they already support Jenkins, but in Mandiri. We use Bamboo for the deployment as well as part of Jenkins. We also install other monitoring tools, such as AppDynamics, for collecting information on performance and the problems of API Gateway hosting services. 

With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance.

With their API-Portal, you need to have flexibility when changing the layout and teams, giving more flexibility to rearrange and do some type of UX/UI that fits into your organization. The API-Portal that comes from Software AG has some of those limitations, with only certain parts that can be fully customized.

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

They should develop clear visibility for the onboarding. They could also improve the clustering.

This solution could be improved by offering subscription based licensing.

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. 

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

I am not satisfied with the solution because it takes too much effort to migrate and add new information. The migration could be easier. There's a lot of rework that needs to be done if you go to a newer version.

The products, at the moment, are new and there should perhaps be support for the older version of the protocols. While I know that they have the new versions, which are actually needed, I don't believe they have that capacity when it comes to any integration with older systems. This is because I believe us to be more advanced nowadays, with what they are doing for the roadmap of new technologies.

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.

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.

On the API monetization side, being able to create separate consumption plans and throttle all those consumption plans towards the run time. Those are abilities that might need some improvements.

The on-premises setup can be difficult.

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.

I think rules engine processes and BPM processes should be improved. I think they must accommodate the future of the communication between systems and that is related to web services and the like. 

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.

There is room for improvement because Software AG is leading to the market for the IO, for the iPass so they may have to improve a lot on the other data, like scaling and also some of the connectors to different types of cloud applications. I doubt they have all the connectors to all the applications, like other products have. They have standard connectors like SAP, Salesforce and the others; they need to have Azure, and AWS, all those connectors. In general, improved scalability and connection to different cloud applications would make a big difference. I think that the product is not completely mature and they need to do some work on that. I would like to see a reduced price for the solution. 

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.

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.

Perhaps in the area of Microservices, where I think Trading Networks could benefit from some improvements.

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

The configuring of the JWT token would be improved as it is a confusing process. We require more information on this part of the solution. 

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. 

Some of the things that we use cannot be done in this solution. For these things, we have to either use a Java service or a util service. There is no predefined or existing service that we can use. So, we have to work on the util service and write on top of it.

Its price can also be better. It is pretty costly because they charge us for each transmission.

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.

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.

• Broker
• Trading partners
• Portal

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.

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.

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.

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.

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

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.

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

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

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

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.

Configuration and interaction of trading partners in the TN with an ActiveTransfer product.

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

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.

webMethods Integration Server needs to add more adapters. 

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.

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

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.

The solution could be improved in the VTA part.

The solution should include REST API calls.