The thick client interface is one thing that needs to move on. The as well should provide a better Web Based UI for policy management.

I would also like to see more streamlining between Gateway and integration with the Portal for Collaboration.

I recently got to know through some of my sources that there is a lack of support for customers from Broadcom's end. Broadcom's technical support team needs improvement. Broadcom's technical support team needs to be improved to achieve an increase in business in India.

The development portal could be improved. Following Layer7's acquisition of Broadcom, the technical support and sales teams have not been good and both those areas need to be improved. I'd also like to see the latest code support with open API specs and JavaScript which is lacking. 

In terms of what could be improved, I think they do not have a good enough knowledge base on setting up the API Management Layer, especially on Azure using containers. In the corporate world, this solution is becoming very popular as we move forward.   

So something that I would like them to improve on is their information resources because we need more assistance / support from them to get our API Management Layer set up correctly on Azure. They still have a lot to do in this area in terms of support and building a community. But we have confidence, it would improve moving forward.  

When you talk about full API life cycle management, they lack inbuilt support of community forums as part of their offering which can be published to external developers. The forum can become an important hub for communication between our organization’s API Team and app developers who wish to use our APIs. Using the forums, developers will be able to post questions using the forum.

The product's initial setup phase is not very straightforward, making it an area where improvements are required.

Layer7 API Management could have a live API creator feature, so my team can easily create APIs. Right now, the product doesn't have that feature.

There is room for improvement in terms of innovation and investment, especially when compared to other leading products in the market.

Building the marketplace on layer7 is not so easy. It's not so easy to do some onboarding workflows.

It's quite satisfactory. However, I don't focus much on the cost perspective, but I understand that clients are often concerned about costs. They might be exploring other options due to the high cost associated with our current package.

Currently, we don't have any major issues, and any past issues we encountered were promptly resolved. Perhaps in terms of improvement, we could explore more robust connectivity options, but for our current needs, it's been solid. As for my company, we might consider migration, and there are tools like GMU migration, provided by the same vendor, which could potentially help us in that regard.

Layer7 API Management should improve the quota policy for the number of API calls. 

I feel like Apigee's API product is more interactive. You can drag and drop with those, but it's a little more difficult in Layer7. It's less user-friendly compared to that Apigee product. However, the overall user experience is okay. 

On the monitoring side, we need a better way to monitor it. CA has not given a clear understanding of what external tools we can use to do this.

We also need a total dashboard functionality to see how many transactions are going through, where the problems are, etc. There's no out-of-the-box monitoring other than the dashboard, which doesn't give you very much.

Their migration policies are also not the best out there. We just do an export and import of it, which is fairly simple, but they could have made it better.

With scalability, it comes to resiliency. If you cannot scale you're not resilient. If you're not resilient your performance is worse. If your performance is worse your API and services are not available.

Fine lines of availability is one of the key criteria's in the industry - 99.99% availability. That means 6 hours downtime in a year, so can you really ensure that everything is interlinked. If we talk about software architecture, quality attributes from these are all interlinked. I would say that eventually, it comes down to your customer satisfaction from there on. So that's our number one goal.

Right now, scalability is our main goal. Maybe they're not the problems but from the standpoint of onboarding a new API on Layer 7, that's fairly simple. I see that it's an extremely user intuitive and user-friendly software. Our operational personnel who have barely have any experience could get on with it and help the enterprise register as many API's as possible from the get-go.

Layer7 API Management could improve by assing more portal-based capabilities.

The solution should prioritize ease of use and align with the growing trend of cloud-native environments. Customers are increasingly leaning towards cloud-native solutions, and while you can configure your topology in the cloud as a private solution, having a more inherently cloud-native approach is crucial.

Layer7 API Management also should feature built-in policies to minimize the need for extensive code writing. It needs to include more plug-ins. 

The Portal lacks maturity. Since the move from Portal 3.x to 4.x, a lot of features were removed. It is slowly coming back. I can see a lot of changes are done in the "background" to decouple components and make it more flexible. Those changes are just not getting to the UI side quick enough.

The CA Portal concept of multi tenancy does not align with their other products (or how most people see it) and that caught us off guard. CA/Broadcom is addressing this though. I have seen an uptake in feature development since the Broadcom acquisition of CA. It seems that a lot of our concerns were taken up and are being addressed. My rating would have been better if it was not for the Portal. The Gateway I would give a 10 out of 10.

For feature improvements, the way the Portal handles the security of APIs needs a total rework. Luckily, we could customise this layer to work for us but it would have been nice if the options were out-of-the-box. As the product set is very customisable, I would like to see an environment where customers could share and upload customised components or "assertions".

The entire lifecycle management approach needs improvement: from the API management, development, deployment, some of the settings around the quotas, and some security policy applications, etc. for the APIs. We found the Apigee platform a lot more robust in that area.

There is still room for improvement for the CA API Developer Portal. It is still not on par with where the competitors are. Other than that, the Core API seems to be very resilient and strong on the security front, but then the CA API Developer Portal is the only piece which I think can be improved. 

The Policy Manager tool that is used to manage the solution is very heavy to use because it is based in Java. Sometimes it takes a long time to load. There could be some improvements to it. If they could make Policy Manager on a web page that would be a good alternative.

I would like to see this amazing product have the following enhancements:

• Continue integration and delivery (10 points)
  Currently the tool provides REST APIs, but they are not easy to use. They need to be reviewed and enhanced. The documentation is good, but there are not enough examples.
• Monitoring and reporting (20 points)
  The Admin dashboard provided by the tool is amazing. However, this doesn't allow the service owners to view their services. The gateway admins are always struggling to provide reporting and monitoring status. We need to provide monitoring and reporting out-of-the-box for the management and service owners. We can do custom development, but not every company has time to do so. The Admin dashboard is not business friendly and it doesn't provide rich reporting features.
• RAD - Rapid Application Development - Development environment (5 points)
  The policy editor, at first glance, seems complicated and it scares developers. I would like to see it easier to understand. Maybe it could have a visual drag and drop, like with Borland C++ Builder.

An as-is string API is not available for manipulating, like we do have in Java all operations of String are not present. The hard way is by using regular expressions, which is little difficult to intermediate and beginners.

Some kinds of errors have to be reworked.

Very recently, I saw a connection reset error message for a handshake (for cipher). Many organizations have recently performed the SHA2 upgrade, so handshake errors are not properly recorded in logs.

When backend system sends error message with different MIME layer7 cannot propogate the same message, most of the times it gives blank message, backend error message is never passed to final consumer.

(observed in 8.3 for MIME application/problem+json and with error code 403)

This is not specific to CA's tool, but API tools in general. There are two schools of thought: There is the "Apigee" school of thought that says that we don't need hardware to implement security, and there's the "API Connect" school of thought which says some sort of an enterprise service bus would be critical to the success of the API management tool. 

I find this hardware reliance is a bit archaic. The biggest reason I would want to get an API management tool is to get rid of the hardware. If I have to have the hardware and put the tool on top of it, that makes it a bit cumbersome for us because the maintenance of the hardware, for any enterprise service bus, is in hundreds of thousands of dollars per year.

It needs to go into virtualization.

There is a thick client for configuration that is not as easy to use as you might like. So I would say the design and user experience, from an administrative standpoint, is a little clunky.

There are some really very granular kinds of issues that I've found and they're more related to very specific technical components of the application itself. Aside from these individual complaints that are very bound up with our use cases, I don't have any specific recommendations.

We did an assessment and are continuing with implementation. I would not say it's 100 percent perfect but, currently, all the features we anticipated using are working. The only issue we have is that we have to buy an APM license separately for end-to-end monitoring. That is something we are looking into.

The API Management has few products - Gateway, Portal. So far both Gateway and Portal are good but we would like to see a bit more improvements on the Portal side like giving a polished look for the documentation on the Portal. The Gateway is kind of solid.

Today it is not that straightforward to generate a document, even the data generate, and it's not really auto-generating it from the Gateway. I would like to see an auto-generation of the documentation. 

The UI design could be improved in the next release.

I would like to see the GMU, the automated deployment framework, available in some sort of graphical interface. This would allow options, outside of automation, so you could see things graphically.

One item that we’ve had discussions – and they’ve fixed some of it – you had to buy extra products, specifically the CA Mobile API Gateway, to get certain types of token support even though you didn’t need that product for anything else.

So, foundational token support should be part of the base product and you shouldn’t have to buy the mobile feature to get those features. For example, in order to get OAUTH we had to buy the MAG product, but I think they’ve fixed that now. But we’re not sure they’ve fixed everything.

The CA API Management solution has good security features, but when it comes to being used in areas like enterprise integration, where it is being used as middleware for all the IT environments, that particular feature is quite limited. It doesn't support as many protocols as an industry standard, competing product should.

One area where it certainly needs to improve is the way it allocates requests, in terms of rate limiting. Let's say I have set the rate-limiting to 1000 requests per second and I have four nodes in a cluster. It divides the request into four, that is 250 per node. If I have a node-balancer in front which has the least connection mechanism it sends the first request to a node. It has to improve in terms of API rate-limiting.

Also, there is no native Kafka connectivity. If they provided native Kafka connectivity, that would be good.

It would be nice if we could create APIs directly from Swagger files. We're doing that ourselves with a middle layer. But if you could integrate with open API Swagger specs, and then just create a Swagger and upload it to the gateway and it would create all my API template policy, and would apply the OAuth restrictions, the types of security restrictions I have on there, that would be pretty cool.

I've used the device since it was the Layer 7 device, and it's come a long way. I think from a mobility standpoint, there's a lot of things that we do, and we have to create our own policies.

I think the product's getting better every iteration, and they're adding more and more functionality to it, that allows us more reuse.

I would just like to see where it's going to go through the roadmap, and I think it's got great, great potential.

Based on a lot of the other tools in the marketplace, the user interface itself is more linear and programmatic based. For a developer it seems to be a very natural interface, but for someone that you'd like to get in there, just doing more configuration, I think there's an opportunity there.

At a high level, I would say the portal is a pain. CA double up portal is a pain. It is something that we are struggling with right now. That is just one of the products which is probably not sufficiently satisfactory. We are struggling to get it installed to be used now.

It is not a fully-baked product as a whole. So, individual solutions may be good, but they are evolving in their silos. There needs to be wholistic thinking about how each one of these products functions. Each one of these CA products under API management needs to work in synergy, and evolve in a more cohesive, coherent way so we as enterprise we can take it seamlessly without much pain. 

There is a need for the migration of policies, better reporting, and monitoring integration.

They have really stabilized the API gateway in the last couple of releases. There’s a developer portal that is used to document your APIs that is woefully behind the times, in terms of being able to provide a really good robust experience for the developers consuming your APIs. You can’t document all of the details you need in the current developer portal and really need a separate web site just to document your API.

You need to understand what you want from an enterprise API, what your vision, what your plans are for rolling out an enterprise API, before you just go out and buy a product.

I see a lot in the developer portal. It's not that flexible the way we want it to be, so it's kind of out of the box and we can only do the standard features that they have. If you want to customize, it's a little bit hard for us, so I really want to see some flexibility in the developer portal. For the monitoring module, I also want to see some stability in the ESM module.

It is not user-friendly because you have to know so many programming languages.

The latest version that just came out at the first of October really was a powerful move in the right direction. I was very, very pleased with that because it allows now beginning to use information of things. We've got this IOT infrastructure that we can plug into, and for my use cases there are a lot of outdoor sensors that provide valuable information to my customers.

As we've brought on MQQT, and other ways of talking to those sensors, that just makes my life easier. I'd to continue to see them expand the scope of the product. But I can say that I've been extremely pleased with the work they're doing. They're not sitting around, every six months we get a release with major improvements.

Larger organizations have a real challenge. They have to control all the people that touch their data, and when it goes wrong - you've seen it on the news recently - it ends up being major headline news story. "Equifax exposes data to 150 million customers." That's intolerable to these customers.

What happens is that the companies that are working with that type of data have extremely rigid policies for who can get access to what. As we continue to develop the product in that regard, we would like to see continued integration with other CA products that accomplish that goal. I'm not saying that it doesn't do it now, I'm just saying that scenario where there can be continuous improvement.

For additional features, I would like to see how it can be deployed into the cloud platform out-of-the-box and not having to do a lot of the initial setup. If it can be done out-of-the-box, that will make customer's life very easy.

Their upgrade solutions are not straightforward. Therefore, we are running the older version. We wanted to go to the latest and greatest. However, it is really complex going from where we are to the next one. 

I would like to see it work better with one of our back-end databases, DB2 UDB. Other than that, I really don't have any complaints so far. It's doing everything we need it do.

The tool itself, I think, could be better. Along with the flexibility it does have, I wish it had a little more modern user interface. For troubleshooting, debugging, that kind of thing, it could definitely be better. I would like to see improvements in the user interface, for sure for Policy Manager. That's the developer's tool. 

Debugging seems a little bit archaic by modern standards. I would like to see that improved. 

I would like to see better documentation for the development language itself. I think they took a step backwards, actually, when they published all their documentation online. Accessibility is better because it's on the web. But the content seems to me to have taken a step backwards. Not enough details, more difficult to find specifics. And you would almost think that would be the opposite, but the feedback I've gotten from our developers, and my own experience, is that it's not the case.

But in terms of the structure of how the language works, it's pretty good. It gives you a lot of flexibility and allows you to accomplish a lot quickly.

So, in general, improvements in the UI, usability. Like I said, it seems dated in terms of how it works, by modern standards. I think they could go a long way to refurbishing the whole UI.

What it allows us to do is it's more time to market than the value, actually, so a lot of our affiliate marketing teams, they go and engage with the vendor's affiliates, effectively, and they want a very quick, clean solution to get a lot of customers in, place a bet, see their bet history and then log out and tap on and move on to do something else. What this allows us to do is that, whereas previously, I would have had to a specific project team, they would take two or three months to do an integration, now you can do that in a matter of weeks. You can realize the value of a commercial relationship very quickly.

They are getting there. Docker-based containers are there now, but it is not completed, I think. There are still some gaps between what we currently have and what the Docker model is. We are going for a pure cloud solution, so I want more emphasis on the hybrid model; deployment strategies that allow me to have on-prem and in-the-cloud interactions using the API Gateway, possibly even defining extended VIPs that we can load balance across the two platforms.

They are moving forward, of course, as they go away from the virtual clients and get to Hazelcast. The roadmap could be a little clear for us because I'm making decisions now for the next generation of architecture. It's a little hard to discern where they're headed.

I want a more loosely coupled migration utility.

Now they provide a DMU for migration of the code or APIs for continuous delivery. But it's not robust, so I want to see what CA is going to come up with regards to that.

In terms of using the tool itself, it is not user-friendly. You can use the product with ease, but once it starts developing the code, there are a lot of APIs and functions that are not readily available for you. You need to refer to a document to learn about that. They should provide some APIs which will drop down the list of all the functions and that are available and ready to use. The world is changing now; we don't want to be stuck in the 80s or 70s, where we need to search for everything and then try to write a code for it one-by-one. It needs be a good tool; easy for the customers to use it.

The main missing aspect from this tool is that although continuous delivery is available, it is not that straightforward and we have to work on that.

In my opinion, the policies need to be simplified so that developers are able to understand and taking that into consideration they can build their APIs. The support and maintenance needs to be simpler.

They need to provide more knowledge and it should not be that only CA is able to provide that service. There is need to pass on the knowledge to the enterprise users.

CA can provide more features to help with performing tests, for example, to create a month of simulated data to perform stress tests using the CA. In the past, we had to pay our client to create a database for us to perform tests using credit card information with simulated customers. We want the CA API management platform to include a specific module for creating this test database.

Some of the things that we see as room of improvement are how do you integrate with other systems out there. Integration with the existing systems and infrastructure, which is not necessarily related. How do you integrate those systems in? Examples could be: how does CA integrate with IBM or existing systems? Lot's of large organizations have existing systems they don't want to replace with other systems. How does CA's systems work with those systems concurrently? Those would be important considerations.

Layer7 API Management’s price could be reduced.

There could be more integration options included in the product. It needs active connections added in the present version.

Some areas for improvement would be the security the product provides and the response time when a client is making a call with their payload. 

There are old algorithms that the tool does not support - and it shouldn't, in my opinion. But sometimes customers need old algorithms, from old use cases and old applications, migrated to the platform. At those times, there are hiccups that happen. It's a bit of a challenge to make the customer understand that we should not be going with these old applications.

I would like to be able to see the publisher role be able to be organized within organizations, so somebody within that role can only manipulate their particular policies.

We are evaluating the next release, actually. We would like to see more stability.

The Policy Manager UI is very busy. It lacks a graphical representation for the flow of the assertions that can significantly improve the clarity of the policy. Thus the Policy Manager UI can be improved in terms of usability. For example, instead of policy assertions in the policy being in a line by line form, it could be represented as graphical flow, similar to how Vordel Gateway does it.

It's a great product. Just expand on it. I think CA has done a good job bringing the UI component to macOS; that’s good. And I think they're also doing a web UI version where you can create policies. I believe in the past, they had some limitations of what you could or couldn't do, but they are solving some of those issues.

CA is the leader in this space. So we look toward them for coming up with best practices to adopt. I'm not really an expert in that area.

I would like to see a lot more information about design, such as design thinking and design UX, UI, information about the technology, and the problems it's solving for everyday customers.

We would want to see the monetization feature to be a standard function. At the moment, it is a third-party solution. This feature helps you to carry out API billings, so as the APIs are consumed from the outside world, you can charge your users for using them. Currently, it is not a standard feature and is more like an add-on where they have worked out ISV pricing with others. So, if it is made as a standard feature of the product it will be really good because it will take the promise of app economy to a true level; thus, it will be truly monetized.

Another improvement we would like to see is that the product should be more relevant with the public cloud infrastructure that is pervasive nowadays. So, the ability to host and run these solutions on Amazon, Azure or Google Cloud should be a standard feature for this product. From what we have been told it is going to be a part of the product’s roadmap.

The Developer Portal has had some limitations but a new version has already been released which addresses these limitations. It is already available in SaaS form and will also be available as an on-premise solution this October.

The previous version of the Portal was a bit more limited in terms of appearance customization (CMS) than the new version. Some other features lacking in the old portal but available in the new version include API-Enabled (functions that can be executed from within the web-based GUI can also be executed from API calls, allowing you to automate tasks), ad-hoc reporting, support for hybrid deployments (Portal in the cloud, API Gateway on-prem), and Swagger support to name a few of the most commonly requested features.

I'd like to be able to import a Swagger file through the gateway.

From the last version, they have added more dashboard support, but there is still a lot they need to improve. The thing is, on the chart you can set it to forty seconds or one minute. That's fine, but if you hold any request it should be clear on the graph. For instance, on the dashboard of the graph it should be written around it. It should say, this is the response time here, etc. In terms of monitoring, it's almost all covered. The interface can be improved, though.

Its ID authentication is a little outdated. I think they should start using face ID.

They need a multifactor authentication solution for the API layer and the other layers, as well. Today, we don't have face recognition for the gateway. We don't have palm recognition either. This would add a needed additional security layer.  

The user interface — what they call the Policy Manager — is somewhat poor but I think that is because of the technology they have chosen. It is a Java desktop. The user interface for a Java desktop is difficult to make and it is not easy to make it look flashy. If they move to a web interface, that is another problem.  

It cannot match the native Windows interface, but it is okay. It needs to be improved, I guess. That is the only thing I believe needs to be improved in Layer 7. It needs to be easier to navigate and use.  

I would also like the next release to support FAPI-CIBA because there are laws in Brazil that require companies that operate in a digital manner to support CIBA and FAPI. This is more for authentication flows.

The development toolkit used for creating APIs should be more online and user-friendly. 

Deployment and tracking could also be improved. Tools like Apigee provide a complete online experience along with RESTful APIs, to manage all activities. It is a very nice and user-friendly solution compared to CA.

The portal is an important point in the lifecycle of the APIs. Right now, the portal lacks many features. We hope that the new version will have them and that there will be a quality jump, which is needed.

We have cases open around the SQL injection capabilities that need improvement. Cross-origin resource sharing policies need to be made a common assertion in the Gateway, that's not there at the moment out of the box (although it is available as a policy fragment). 

The developer portal needs to fully supported SOAP services (including WSDL publication with security), it would certainly push adoption for us.

The additional features are to keep up with the security aspects. That’s one aspect, the market is changing. As we started several years back and where we are today, the technology and the security aspects have pretty much changed starting in the good old days with the PKI, SSL, now with the OR, etc.

One thing that I would really look up to is keeping up with all of the evolution and security aspects of it as new features that can be added. The second one is provisioning the users. Right now we do not have a user friendly provisioning utility per se, so we have to do it behind the scenes. Having such a feature would certainly help in the long run, because it could do a lot of internal effort that we have to do in terms of development and maintenance aspects of it if we were using something out of the box.

I was hoping that there would be some deeper dive Gateway training than their two day workshop and the self-paced study provided. The only course that focused on the Gateway was a Sales Certification course, for which I never did get my certificate, and it was only a short intro to the Gateway and the Portal. There was nothing that I could find that was more in depth than that.

Some of the speakers at CA World spoke about how they used the Gateway, but mostly it was mentioned that partners were using it. So it would be good if there could be more deeper dive Gateway training during the Pre-Conference training sessions.

The license model and the cost of licensing can be improved. Especially given that we are in a stable operational mode.

The more automation the better. I think CA is stepping in the right direction. I went through the micro API Gateway presentations here at the CA World conference, on how you can automate more of the policy deployment via the JSON format, so you don't even having to touch the Policy Manager. Because every time you touch something in the Policy Manager you think, "Well, that's a GUI, humans need to go in and do something with it." So if we can automate everything with the APIs, that helps a lot in the DevOps lifecycle, where we want to automate everything.

I would like to see more documentation. The current documentation is there, but we do not find it very useful. For example, we wanted to integrate with PingFederate TV provider and there was not enough information to customize the way we wanted. It took a lot of effort and we had to reach out to the Gateway folks to help us out on how to do that customization. Thus, it is not easy to integrate with other solutions.

I would like more graphical interfaces for better usability.

The overall cost of Layer7 API Management is high, they can improve it by making it less expensive. It is a stable platform, but Layer7 API vision and future are not clear

We have experienced technical difficulties with the product in the past. 

Cloud-native architecture of the product.

• More throughput
• More scalability
• Better built-in monitoring

The product shouldn’t require to be connected to a server for doing development.

The products developer portals can be better. It needs a better look and feel.

Also, the user experience for developers to discover and develop APIs needs work.

Some of the common useful functions/assertions (e.g., JWT encoding/decoding) are only available in other CA products. The client needs to purchase and install those products in order to make it available for Layer 7. I don't think it is justified to maintain another product that is not really needed, in order to have just one function. If those common, useful functions could be part of the core Layer7 product, that would be great.

Provide complete documentation with examples of usage on its build in assertion/function.

Easier to find documents (e.g., cluster setup).

The delivery is bulky in terms of implementation. Its price could also be better. It is a very good product as compared to CA API, Google API, and WSO2 API, but its price is high.

From the cloud-native perspective, some new features need to be added. It could also be made simpler to implement.

They should incorporate deeper monitoring features into the solution to make the offering more complete. Doing so would help to showcase traffic patterns and usage to better engage customers and partners proactively. It would also help with API management and capacity planning.

We're integrating the cloud. I would like some more integration of cloud capabilities.

The solution is divided into their Gateway and to their Developer Portal components. For the Gateway component, our expectation was that it is provided as a Docker image, but it turned out that it was not supported in production up to the version that we are currently using. But the next version is obviously provided as a complete containerized version for production, which is quite good.

On the other hand, the Portal provides some questions so to speak, at the moment, because as we decided on the product last year, at the end of 2016, and it turned out that CA completely rewrote the Portal solution and the current version of it is not at the level of the functionality of the previous 3.5 version. That's quite a problem for us because we expected some functions in the Portal which are currently not available. Unfortunately, the new version is also not being introduced here at CA World, so I'm somewhat doubtful as to whether it will be provided this year. So it will probably be available only next year.

• Patching/upgrading is a manual process and should be automated.
• Configuration synchronizing between nodes (installation instances of this software) is a manual process and should be automated and simplified.
• It could use a better dashboard for showing performance metrics (e.g message throughput).
• Ideally there should be cheaper development/testing (ie. non-production) licenses available to customers.

I don't have enough experience to say what I would like to see improved because I'm still building it into my repertoire right now.

I wouldn't say, however, that the setup is simple. It's mildly complex, but given the documentation and the linearity of it, it was fairly straightforward.

Based on the method an API, we need to be able to access that particular API.

They need a workflow for the API Developer Portal, where the process only allows requests to go to the correct person.

The CA Mobile API Gateway (MAG) for mobiles has too much latency.

The feature set is quite diverse and community driven, which is a good avenue to promote future features into this product.

The policy manager UI shows signs of aging, but it is not a must.

Policy manager is probably built using Java SWING, it has all the features, but loses some points on the look and feel, compared to some new generation IDEs.

It would be nice to see the PM revamped and some additional features added, such as step debugging for encapsulated assertions etc.

The UI is very dated. I've talked to some of the development and product managers about that, and I think it's a known issue. It's early 2000's technology. We would like to see something online and a better UI that's easier to use and more intuitive.

Reporting could use some enhancements as well. We just moved to the 8.4 version from 7.1, and they've got a new reporting tool called ESM. We're just now starting to use that, so maybe that's going to provide what we need; it's to be determined.

• The API Development tool can be made more user-friendly by providing folder properties.
• Assertions for common functionalities (like mathematical operations, string manipulations, connecting to non-SQL).
• Masking the user credentials entered in Identity Provider, JDBC based on user role
• Analytics and reporting need to be made better and more user-friendly; add some custom reports both on the Developer Portal and API Gateway; exporting of analytics and an email facility.
• Logging and tracking of changes done by users in the Developer Portal.

• Better GUI for the policy manager.
• Needs better professional services in my country. 
• Better mobile features.
• Better HA configuration.

More developer focused tools. They have a nice debugger inside of the program, but when you are developing code with their policies, it is tough to visualize that sometimes as a developer. So, tools that are a little more focused on rapidly creating those policies would be beneficial.  

• This is a punctual need for the characteristics of the business or at the request of some partners: It is the use and configuration of VPNs, which in the current version is not enabled.
• Expose system properties and other configurations via the GUI (Policy Manager).
• Increase tools for manipulation of JSON messages.

Microservices gateway is one thing in which we thought would be really good. It has come up, we just have to see how it's going to play out. Obviously, it's not going to replace the classic gateway, although we want to see that something in the microservices gateway that can actually replace classic gateway. That would be really nice. Right now, I don't think it's completely replaceable. It's just a part of it, but eventually they're saying that it will replace. So one day, where we can have a microservices gateway and we will not need the classic gateway at all, that is what we want to see.

As well as the SOA Gateway - that is, the API Gateway; we call it the SOA Gateway - we also are now deploying the developer portal component of the SOA Gateway. That has limitations.

There are two main ways to offer web services to the outside world at the moment. One is RESTful services and one is SOAP-based services. We are predominantly a SOAP service company and the support for SOAP-based services are very limited, almost poor, in the developer portal. All CA's investment is around RESTful services, which is a problem for us.

I would also simplify threat protection, I would improve SOAP support, and I would reduce Professional Services rates. Apart from that, everything's pretty good.

Improvement in developer portal customization.

There is a need to automate the process of retrieving the SSL certificate when it has expired. Currently, the product doesn't have this feature automated. It is only manual.

Because of our experience with our cloud-hosting provider's image requirements versus what CA provided them, I think an area of improvement would be additional form factors for virtualization.

The product needs to keep up with newer trends even though customers might not be requesting it yet. For example, the usage of newer versions of Swagger and YAML format.

We are looking for improvements related to integration. We want to see them add integration tools to the CA bundle. That would be helpful.

CA API Portal 3.5 does not support Swagger documentation. If they were to support that, it would be great. However, their focus is on a newer, enhanced version of their API Portal 4.1 Release. However, it is not very mature and there is no direct migration available in the near future. It is not possible for clients to migrate to a newer version.

CA might lose clients mainly for this reason (Swagger Support on API Portal 3.5), unless they develop seamless migration utilities from API portal 3.5 to 4.1.

I feel there is a lot to improve in terms of providing plug-and-play functionalities, as at the moment it requires a lot of coding in their specific language for implementing a medium-complexity use case. It needs to improve the user interface for logging and monitoring. There is no test framework for the APIs, which is a setback. And with respect to providing an end-to-end API management solution, where the API will be charged per usage from the client, configuration is not that easy and straightforward.

We'd like to see an updated migration tool. Right now, the migration process works but it is a little clunky because there's not a good tool for migrating it. It's an older version tool so the services need to be restarted every once in a while.

One improvement for CA API Management would be better integration with the web access console. Better integration of the web access console would be great.

One specific feature that we need is the ability to authenticate directly to the server with API data. It's not complex nowadays. This is a feature that we need and CA doesn't have it. 

CA API Management can't do the same authentication functionality with the APIs as the other competitive products in the marketplace.

• Ease of use
• Ability of development and ops teams to expose and manage their own API

In two months, we want a new API publishing system to be opened. We need them to have fixed the issues of the API gateway by then.

The portal is not the most intuitive and the way things are displayed makes it difficult to find the information we need. We never completely read the info. The way it's written does not make me want to read it.