An improvement could be the usage of OpenAPI specifications. Currently, it uses other standards, but adopting OpenAPI, the standard in the market, would be beneficial.

From a monitoring point of view, MuleSoft Anypoint Platform can improve on tracking transactions. When dealing with multiple transactions or trading, the system can lose control, and tracking becomes hectic. Enhanced monitoring can make transaction tracking easier.

One area for improvement is the Community Hub or developer portal, which should be part of the base offering. Additionally, MuleSoft is considered expensive, so pricing is a major concern.

Over the years, Mule Anypoint Platform has undergone significant improvements. When I first started using it, the API gateway capabilities were fairly basic. However, they have evolved into a mature API gateway solution. In fact, they are well-regarded in Gartner's evaluations of API gateways.

While Anypoint Platform has made strides in monitoring and reporting functionalities, there is still room for improvement in this area. Enhanced reporting and more robust monitoring capabilities would further strengthen the platform's usability and appeal.

One area we'd like to see improvement in is the error logging and troubleshooting process. Handling errors can sometimes be challenging, but if Mule Anypoint Platform could allow defining user-defined errors and provide better management for them, that would greatly enhance the platform.

Another aspect is the support from MuleSoft. We don't find it easy to get support from their product support team. I'm not sure if it's an issue with our specific team, but the responsiveness from MuleSoft support should be better. We rely on their product for our work, so that's something we hope could be improved.

Mule Anypoint Platform should improve its pricing. In my experience, a customer using the sandbox version couldn't upgrade to the final version because it exceeded their budget.

Another area for improvement is the login mechanism. We need to integrate with third-party products for strong authentication, but it would be better if MuleSoft had its own robust login mechanism.

The main area where improvements are required in the product revolves around budgeting. The cost of the product is an area of concern where improvements are required, especially when compared to other tools, like Dell Boomi or Oracle. Mule Anypoint Platform is made available with many components, and whether users use them or not depends on their choices. For example, though there is a tool called Anypoint MQ, our organization prefers to pay and use Kafka, as we don't want to use MuleSoft Anypoint MQ. In Mule Anypoint Platform, there needs to be proper segregation to help users identify what they need and don't need, making it an area where users need to be careful when opting for MuleSoft. Mule Anypoint Platform is an integration tool and not an ETL solution. When a user has to deal with a huge number of data, then Mule Anypoint Platform should not be a preferred choice since it can only be used for lightweight purposes revolving around APIs. There is a need to have a clear architectural decision made before opting for Mule Anypoint Platform. When there is a requirement for heavy data transformation, then users need to decide whether to go with Mule Anypoint Platform or any other platform available in the market. Though the tool comes with many useful components, it depends on whether the user plans to use all of its features. Recently, the product has come up with a new feature that is similar to an API catalog. MuleSoft had come up with the UAPIM feature almost eight months to a year ago, which had some concerns in the area of budgeting. Whether you build APIs using Javacore or any other tools, they can be cataloged using MuleSoft's UAPIM feature, for which users need to pay an extra amount, making it an area of concern for users.

It would be great if MuleSoft's support team could provide help with the area of Kubernetes.

Anypoint Studio for developing integrations can be described as a moderate to complex process, and from an improvement perspective, it needs to be made easier.

Mule Anypoint Platform has developed a new development studio based on Visual Studio Code, but it is still in the beta stage, so my company hasn't used it yet. I hope in the future, it will be easier to use the tool because the current Anypoint Studio is based on scripts, which are quite heavy. My company hopes that in the future, with Visual Studio Code, the development studio would be easier to use.

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

The price could be improved.

The product does not provide a priority level for the message. It also does not have Topic. It has an exchange instead of Topic. The users request for the Topic functionality. Such functionalities are available in ActiveMQ. There is a limitation of 10 MB for messages. It's something we must take into consideration when we have a large payload. The storage must be expandable. We shouldn’t have to do additional setups for correlation.

With GenAI coming into the picture, it can be used to focus on specific setups and use cases. If you want to have an end-to-end solution, more AI infusion into the product will be beneficial. For example, when it comes to an industry-based solution, and someone approaches our company and states that they want to focus on healthcare or some financial services, we have some specific end-to-end solutions where Anypoint can be used as a backbone. If you are able to enable some AI on top of the functionalities provided by the product, it would be beneficial for users. The inclusion of GenAI in the tool can be good since it is an area that is currently unavailable in the solution. Mule Anypoint Platform can serve as a backbone when trying to build up an end-to-end solution using AI.

The solution's licensing methodologies could be improved.

I think in the next release if they could work with the low-code platform that developers are struggling with that would be helpful. I would like to see some data integration and automation.

The stability could be better. That said, they are also getting stabilized as part of increasing the versions and working on that. Previously, Mule version 3 was, of course, very unstable. However, now, version four is pretty stable now.

There have not been very good resources to help us find solutions to issues. 

Mule Anypoint Platform could improve by having better integration with MDM. There are challenges when doing the interaction at this time.

The product is expensive.

In terms of improvement, the deployment time could be a little shorter. Other platforms such as Boomi or SnapLogic are much faster to develop. Anypoint Platform has added the option to generate flow online, but it still needs some improvement. It should give better control over account management. Mule Anypoint Platform includes an API Manager and it has a strong ESB. However, the API management capabilities of Apigee offer more advanced and dynamic features for managing APIs. 

Additionally, Mule should work on reducing the complexity of their platform and providing more flexibility for users. Those who are not well-versed in Java will have a hard time with the development of Anypoint Platform. While it offers connectors, the connectors have limitations. It should offer features that can be customized by users, allowing for greater adaptability, and offer customization options within these connectors, to make it easier for users to tailor them to specific needs. Platforms such as Dell Omni and SnapLogic already provide solutions for these problems and allow users to easily plug them in and start working.

When it comes to external systems, we need to use APIs. So, it needs some extra effort.

When we are integrating with other applications, readily available connectors make it easy. However, when it comes to external applications, connectivity isn't as straightforward. 

We need to use RESTful APIs to get and push messages. While it's doable, it's not as simple as using the pre-built connectors.

In future releases, Anypoint MQ can increase the message size limit a little bit. We faced issues while working with SAP integrations. SAP can have very large files, and we couldn't handle those within the Anypoint MQ limit.

It would be better if we had a clearer view of the solution's future releases. Mule Anypoint Platform is migrating to a new JDK, and the old JDK won't be supported within a year. Currently, we do not have a calendar or scheduler about when all the connectors will support the new JDK 17.

The platform's data integration tools need improvement on the processing side. We move large amounts of data from databases to other source systems and the solution does not handle this well. 

It is difficult to become a partner with the solution because their standards are very high. 

Although the solution's proxy design and process are good, it faces connecting issues because it lacks data integration. You have to filter the data before integrating it.

The initial setup should be made easy and the documentation should have some guidance. 

The negative side of MuleSoft's Anypoint Platform is its cost. The solution's pricing model is very strange, and it will be really expensive if you use APIs a lot.

The compatibility with vendors can be improved. Microsoft Azure heavily uses single software.

Compatibility with other services or cloud providers like AWS or GCP is not very well defined. This is an area they need to be a little more cautious about.

Nowadays, everyone is talking about Generative AI, how intelligence can be brought into different systems that are ready. If we talk about Mule Anypoint Platform, the system and data are there, but the integration layers are not very advanced. They should bring in Generative AI and other AI platforms because even it will need a lot of self-building intelligence and decision-making.

They have good competition from cloud providers nowadays. There is a lot of scope and innovation competing in that area. 

It's extremely expensive to change things in Anypoint MQ, e.g. we have to go through either Accenture or IBM. IBM will do the changes, but the actual change we ask for costs huge amounts of money. I'm not sure why that is, or whether that's just a contract, but they always complain about multiple changes, regression testing, etc. It sounds like it's a very long winded task just to make a simple change. This is an area for improvement for Anypoint MQ.

Another problem we have with Anypoint MQ is that some of our end systems cannot cope with the throughput. If we put too many messages down to it, then there's a delay to send those messages onto the system that can't take them in as fast, and this means that the queue blows. We have either a 40 gigabyte or 40 megabyte queue space, but if we send 7,000 messages which need to be combined and sent out, the queue blows, because it just can't manage that throughput because the output is so slow. With the memory, we don't have a big enough queue to cope, so there's that problem.

If there was a way around that problem, we could send it. What we need to do is to be able to send 50,000 messages an hour or more, which we can do SAP to SAP, but we haven't found a solution on how to cope with sending it to Anypoint MQ because it blows up, so that's the big problem we have.

What we'd like to see in the next release of Anypoint MQ is for the issue of slow output of messages to be solved. Even if we wrote into disc, e.g. the disc space is cheap, so if you could write the messages to disc and then just feed them out and when the queue is caught up with itself, that would solve our problems. It means we could send MuleSoft all the messages in one go, and then it could drip feed them out.

The additional feature we'd like to see in Anypoint MQ is to be able to write the message queue to disc, to allow for ample queueing of messages, because currently, the output to a particular system is slow.

Anypoint MQ's capabilities are mainly used for messaging purposes, but it doesn't have typical use cases that extend as far as other Message Queue software.

For one, it would be helpful, from an additional features perspective, to see that it can handle large files of any type, whether image files, video files, etc. And if they would include an SFTP solution such as is available in AWS or Azure, this would be an added advantage for our clients.

Anypoint MQ is not a pure messaging product. There are so many solutions like this, but this is not as mature as those products. The other MQ products have the capability of reprocessing and maintaining the persistence of the data. They can handle large volumes and large messages, but Anypoint MQ doesn't have those capabilities.

It can only handle a maximum size of 10 megabytes. The other MQ products have a larger capacity. IBM MQ can handle 100 megabytes of data or even solid gigabytes. This doesn't have that capability.

This solution has a lot of gaps. It's not a pure MQ product. We have sort of exposed this product with different protocols like TCP. Also, it has to evaluate these capabilities compared to the other market products.

There are issues with dead-letter queues.

I think Mule Anypoint Platform is one of the market leaders, so our customers prefer it, which is why I also use it.

The solution's user interface has shortcomings and can be made much better. Mule Anypoint Platform can be made more user-friendly so that people with lesser technical knowledge can understand the product. Mule Anypoint Platform can get too complex for non-technical people.

The pricing should be improved, it's an expensive product. 

One of the issues I have is that Jira tries to be more than an API-based integration platform and it encourages writing of Java-based applications underneath the cover, even though it's not meant to be an app service, so it's slow. That's how they try to sell it. The solution has three layers; the experience layer, the process layer and the system layer. The system layer is used to connect the systems; the process layer can be used to create processes like transformations, logic, etc.; and the experience layer is used to interface with whoever's going to consume it. The problem is that the process layer is not efficient. It acts like an interpreter and interpreters are slow, and if you give it some path like converting to a 100 kilobyte file, it takes 15 times more memory than if I just wrote a program 

When you try using it for the processing layer, it doesn't work well. We ended up pulling back to .NET for our own internal microservices that do a lot of processing. We use the .NET microservices as the process layer, because we know it's faster. Then we plug it into Mule to experience the API interface and that's when we need to make a choice, do we put our system APIs right through our microservice, or do we use Mule as a system API layer, but then let it interface with our process API. We just had to make choices.

The tool requires programming language. 

The solution's licensing model is expensive and could be improved.

In order to set up a storefront, we currently rely on a third-party solution. It would greatly enhance our operations if this feature was integrated into their existing solution.

Some of the functionalities are hosted in the cloud, which occasionally poses challenges when integrating with on-premises applications. Improving this aspect could be beneficial for a smoother and more seamless experience.

Code quality, Code Security, SaaS, and DaaS security, can all be improved.

Mule Anypoint Platform could improve by having more up-to-date adapters to do work in a digital space.

Its documentation needed a little bit of work to make it more usable. It is a platform that is used mainly by developers and other people for connecting systems. Its documentation was confusing in some areas and was not very helpful in other areas. I had to go to a consultant to get some work done, which ideally shouldn't be required.

I don't know if there are any real pain points per se. 

The terms of use and how it's priced has become very difficult to manage, which is forcing us to look for alternatives already - and we haven't even been using it for that long just yet.

The initial setup is rather complex.

There should be more templates associated with a standard to large ERP. There are 18 interfaces required between HighJump to SAP, our warehouse management system. Those templates are standard. Everybody that has HighJump and that has SAP would have to do those 18 interfaces and they should be in a template - yet those templates don't exist. Due to that, there's too much API building from scratch. They should be able to build an API library.

The transforming message is an area in the solution that needs to be improved. There is not much information on the internet, and since MuleSoft is new, there is nothing to research or find in Stack Overflow.

They are probably trying to test two layers at once. I don't know how that would be possible. I've been trying to work between something another company left recently. So while testing it, it's been hard because there are a lot of layers, and some of them are not okay. If I could test two locally, that would be great.

What I hear from my customers is that it's very expensive compared to the cost of other integration suites. The cost keeps increasing. MuleSoft should come up with customization factors by using a different way of getting the cost-related stuff to attract customers. That is, they should come up with some cost optimizations.

In the next release, I would like to see deployment automations.

I would also like MuleSoft to come up with a central platform because with on-premises and hybrid environments, where some are cloud-based applications and others are on premises applications, a DPC setup has to be done. It would be good if they can implement one centralized user interface that provides all of the facilities.

The pricing can be a little bit less. Sometimes the price scare off potential users. 

Adding connectors for new upcoming applications would add extra value to this product.

The solution is very expensive. They need to work on the pricing.

Technical information is not always easy to find. They should work to make it more accessible. 

As far as improvements, the runtime management in MuleSoft can be much better. It has some issues, or we have issues with it.

As for additions, the first thing that I want is for them to create their own connectors. That is very important. Other things beyond that are hard for me to imagine right now especially because they have a lot of features already that we are not yet using. 

One should have hands-on experience on the DataWeave. If somebody knows MuleSoft and is planning to work closely with the solution, they should be comfortable with DataWeave.

Pricing is one aspect of the solution that is troublesome. There should be a lot of improvement in general, as this is a premium product, I can say. Most of the customers like to go ahead with MuleSoft implementation, but at the end of the day what is happening is when they go ahead and see the pricing, they get scared.

Performance-wise also they need to improve a lot. Basically, the number of ports is lacking.  When you have ETL kind of transformation, ideally it will be supported, however, we end up using a large number of ports. That will drastically increase the cost to the customer, however. They need to be able to allow for an increase in ports without expanding the price.

Everybody's now integrating with AI and ML kinds of features. They need to add more of these features into their offering as well.  

The scalability on offer could be better.

Better documentation, in particular with respect to the initial setup, would be helpful.

It has different types of subscriptions. For platinum or lower subscriptions, there are not too many things that can be done. We don't see many features. They should release a basic version that has logging and monitoring features. These features should come with Mule Anypoint Platform for free instead of making customers pay separately for these features.

Its dashboard can be improved to have a lot of charts so that it is easy to visualize information. The utilization part can be improved. The dashboard is good currently, but it can be better. Other solutions like Elastic have a good dashboard, and they allow you to administer the product from the UI. Currently, for RTF, there is a different dashboard or utility. It would be good to include the same utility in the cloud solution.

It would be good if there is a centralized repository that includes the links to the information about various troubleshooting issues. The documentation is there currently, and it is good, but the troubleshooting information is too scattered. We have to go to different links to find troubleshooting information. This kind of centralized repository would be helpful for new customers who are implementing this solution. It will be helpful to see different kinds of issues that can occur.

With regard to the integrations, I'd like to see something similar to the features you find in Dell Boomi related to the intelligent management data and intelligent mappings. Those would be helpful improvements that would help developers. For beginner users with little technical knowledge, some low code would help. 

The solution is Java oriented but doesn't require Java knowledge which is good. But when you are debugging something or when you have other issues, it's important to know a little bit about that. I'd like to see some simplification. Anything that can be automated in the Data V area would also be helpful. 

The product could be improved by having available more information on what's happening with the monitoring, as well as simplifying the login process. 

In terms of improvement, customer support is a bit slow. I emailed the sales team for a pricing comparison, still no response. The developer community is far more generous on the other hand. Pricing model is very expensive, Mule should consider Pay as You go model. It will help on-boarding new clients in Asia region. 

Mule should have better B2B integration. Mule supports the idea of API Led Architecture and system of records approach. When it comes to broad perspectives such as B2B, competitive tools have better EIPs. 

Overall, I think they're keeping pace with the changes that are happening. I don't have any complaints about anything. They could just improve implementing the integration.

I would also like to see some kind of monetization of A-P-S. That's important.

Technical support needs to be improved, especially when you need help with more technical aspects of the solution.

MuleSoft's release calendar is rather conventional with two major, two minor releases and hotfixes in between. The competition sometimes offer more rapid release cycles and provides improved and new functionality with a faster time-to-market.

Some improvements are required in the batch component in case of errors in the batch steps and when processing a large volume of data.

Mule Anypoint Platform is complex for beginners. Users without programming skills will find it complex. It should also improve its pricing. 

The solution is very costly. The solution should provide a package with fewer capabilities at a lower price for specific companies that don’t have a big IT budget. Not every customer requires all the capabilities of the software. It will be a good fit in the market, and they will easily sell it more.

Anypoint MQ could improve the user interface.