I have mainly implemented using Layer 7 API Management. Some of the major challenges we were able to meet with a quick release to market methodology.

Some of the tasks which we achieved for our customers were:

1. Translation service from SOAP to REST and vice versa.

2. API service to DB (Oracle, MySQL, MSSQL, Snowflake, SAP HANA) -- Created Swagger APIs that were able to perform CRUD operation to the backend API mentioned above and provided routes to query and get data.

3. Integration with Payment gateway service providers to perform (transaction on behalf of the customer with third-party payment gateway service providers white labeled with our APIs ) -- Followed TMF standards for payment gateway integration with the Telcom world.

4. Orchestration of the API. Build multiple microservers and provided orchestration based on route, path, and data in the request and perform actions that would be communicated with multiple APIs and provide a single consolidated response.

5. Provided API-driven security (Oauth 2.0, JWT, SAML, Basic, and a variety of means) to access the API giving the developer the freedom to concentrate only on application/service/microservice and let the gateway handle the threat.

6. Seamless Mutual Authentication allowed good segregation between APIs in the DMZ and internal network.

Layer7 is the most important step in our Application Modernization strategy. We envision to create an Open Architecture which allows us to adapt to ever-changing market needs. It is a key enabler in decoupling the core applications from the digital channels thereby giving us the flexibility to build the plug n play architectural landscape. 

One of the main things is the call-ahead feature, where people can call ahead of time with our mobile app to reserve a table at these restaurants. We also have private click-to-call links that are very successful.

Pretty much the whole mobile app is going through our Gateway. People can only access the app through a mutual SSL authentication, plus we make sure that we do geo-location. We also have CA Advanced Authentication to help with this. We put these two tools together to make sure that we are not entertaining anybody outside of our countries that we serve. So security-wise, we feel secure using the gateway.

It is assisting in the uptake of JSON REST services. For quick wins, we are doing the basic transformation on the Gateway and handling all the security ingress and egress of the Gateway. The Gateway technology is an IdP for our APIs as well as in multiple different back-end auth providers.

By handling the security in the Gateway, we can standardise JWT on all internal systems, but do so in a phased approach. E.g migrating from LTPA to JWT.

We adopted SCIM v2 as a user payload standard inside JWT.

It is also assisting in standardising our APIs across the group.

We are leveraging the platform to enforce error code standardisation to RFC 7807.

Developers are now empowered to deploy their own APIs instead of our legacy way of routing everything via a central IT team. This drives the DevOps way of working as the portal exposes all functionalities via APIs once our businesses are integrated into the portal in Jira for external workflow.

Being able to protect our communications protocols, from the back office out to the substations that control the device, is helpful.

The time to go to market has been improved in developing new things while we use this product. We are able to go to market and deploy our functionalities very quickly. We are able to embrace newer security standards. We are able to do that easier because of this product, because of CA API management.

In my last position, the core services were exposed to the consumers via the ESB layer. They had plenty of issues with protecting those services and keeping the back-end services hidden from their consumers.

Using this tool helped them to provide a unique endpoint, with no change to the consumers. It allowed them to change their services without affecting the customer interfaces.

Our organization relies entirely on it for web services and RESTful APIs. Internal applications never get requests if they are not valid or authenticated, which saves the backend server's processing. Big organizations can track demand of services and drives to ROI.

We are a bank, and any API management tool helps us find the right partners to build new products in new markets. Given that we are going down the path of open banking, this type of tool is, perhaps, going to be one of the integral components of our tech deployment.

One of the features that the tool provides is the ability to simply onboard new APIs to an existing security platform. We build all the policies for security upfront, and then we can add those policies pretty simply and straightforwardly to any new API that gets developed in the enterprise. That has been the quickest and easiest thing. 

We're rolling it out across the enterprise as we speak, after that six months or so of heavy usage, and we're finding that the amount of time it takes to secure new APIs has gone down substantially.

We can create multiple orgs and set up policies and management. We can also integrate with an APM solution. We have 1000-plus APIs to be built, policies set up, security handling, and API status in one portal. These are the high-level details. The developers in my team would be able to provide further detail.

It simplifies the operational cost because it is self contained in one container, or one image, so when we wanted to scale, when we wanted to deploy a new Gateway, you could literally do it in like 2 to 3 hours or less than 30 minutes. If you have an automated way you can spin up an automated way.

We also have the ability to deploy it in the cloud if we wanted to. That is one of the very powerful things for us to get the buy-in from our operations team. 

There is not a comparable solution on the market to Layer7 API Management. It has been useful for our organization.

It's benefited us greatly in allowing us to expose our APIs to external third-party vendors in a secure fashion.

It provides a simple endpoint for applications to call and for customers to call, so it reduces a lot of the complications of API services. Most of these APIs the user never sees, like a mobile app that does something below the water line, or another partner is calling our application – such as an order purchasing system at another customer, whose app calls our app. It eliminates the need to deal with users in a lot of cases, so if users don’t have to deal with the system it’s convenient for them. It helps us automate as well.

Let me give you an example from one of my customers, a tier-two telco in the UK. This customer was getting an API that was available to their developers for only two hours a day, and because of this restriction, they had to plan everything precisely for their developers to access the API in those two hours.

Now, with the CA API Management implementation, the third-party API is available to this customer 24/7. It's available any time the development team requires access to the data or the information. This result has quickened the development pace and the testing cycle, and it has saved a lot of our dollars for my end-customer.

We mostly use this product for our internal customers, so it's not a revenue generator for us. We use it for internal customers to contact the IT systems. In terms of benefits, it's not for external customer satisfaction. It's not that kind of a usage here. The benefit that IT sees is, it is a single developer portal for IT; it has helped us provide an API platform to our customers.

It's pretty easy to use, and once we have templating set up we can add new APIs, at least through the gateway, and apply the security to them; it takes a minute. 

We actually have it automated in our Dev environment, where developers can come in and fill out a form with an internal tool. They specify their API, the endpoint they want, this is what they want, and boom, it creates it in Dev and then they can move it up to test and then put in a request to get it to product.

We've used it for so long that I really can't say that it's improved the way our company works, but it works very well for us.

I think the device itself has helped us quite a bit. We're able to do things a lot faster, because of the device. Because we identify the policies, we're able to layer the policies that are already written. People don't have to rewrite code multiple times. We write a policy one time, and then we're just able to just drag it over and reuse it for other things.

If it's implemented correctly and you take advantage of some of the capabilities, like the ability to use APIM on the side and integrate that in with policies, it removes a lot of the weight of building all of those rules into the underlying services. It allows you to escalate that up and put that into policy management that can be managed in real time, which creates a faster move to market with capabilities.

We have not tested it to the extent that we should. Maybe six months down the line we will have a better picture.

We were able to market our mobile app products with their strong security features.

As the APIs are built and published and made available to developers, we can build applications on top of those APIs in days and weeks as opposed to months.

In a traditional web application you’re building your UI, your integration layer, your back end, all at the same time, and there are dependencies – you can’t built the UI until you have database access, etc.

With the API model, all that access to the backend is already available so all you have to concentrate on is building a good user experience.

Mostly, it can identify client IT and user accounts to give them a lot of business logic. It can also provide API versioning. It can provide different versions to different customers, but the original API are the same.

The benefits are rapid development and deployment of APIs, which means that your information, your ability to handle information, to receive it and to send it, to visualize it, to report on it, to get intelligence out of it, happens fast and happens with accuracy. Faster is better.

It really allows us to do things that we just weren't doing before, things that we always talked about doing. Some things that we talked about doing for decades.

One of the things that we talked about doing for decades was the ability to bring data together from different sources, sources that maybe wouldn't otherwise be available. Maybe they were not ours to own. Maybe they were in a place where we just couldn't connect securely to them and enforce our security policies. What we can do is, as those things have developed APIs, we can consume APIs so we're building an API to consume an API to deliver an API. People can keep their roles and responsibilities, they can be responsible for their data integrity, and yet we can use that information to do what we need to do.

We can get more visibility into our data.

The benefit of the Gateway is that it provides security, authorization authentication, and analytics. These are the main benefits which we are using it for. 

Day to day functionality. It just works and it's easy to use, that's the best part of it.

It gave us new capabilities that we really didn't have before. We didn't have a good way of exposing APIs to the internet in a reliable, secure way. It gave us that ability. 

It also gives us a focal point where it's allowing us to consolidate our portfolio. Where before - Cargill is a very large company - from one business unit to the next, they didn't necessarily know what we actually have. This product enables us to consolidate that, so there's one place to look.

It allows us to centralize the triple A functions: authentication, authorization, and audit. It gives us scalability. We can focus on delivery in a hybrid cloud model without exposing any of our back-end services to the market. It's very secure, very powerful, and has a great deal of complex functions that are native in the solution so that we don’t need to write code to do it.

We're moving towards microservices. We do have around 358 to 400 APIs, i.e., monolithic APIs, and we want to convert them into lightweight microservices. We want to deploy them in a container, use the gateway and then expose those microservices to the external world. That’s our main goal and we are using CA API Gateway for this purpose.

Whenever there is a new API development our organization does not need to worry about the security aspects in regards to the API because it's already in place.

It standardized all processes during development with the integration between platforms.

Using this solution, the deployment and development processes become easier when compared to before, when complete Java development was necessary. Now, the encryption part is very easy and our clients don't have to continuously depend on logic. On this platform, it's very easy for them to understand and to do testing. It saves them time.

The benefit of it is being able to create a sense of the API marketplace. It has improved the way our company functions by streamlining the effort and getting people out of the process.

I'm part of an engineering team so this product coming with out-of-the-box security, that is valuable to our organization.

Thanks to this product, we have successfully secured SOAP and REST APIs and exposed them to international/domestic partners using the standard industry protocols.

It certainly filled the API management needs of our organization. For example, we were in the process of designing a patient portal for the hospital, and we were able to quickly leverage the UAR tool kit that’s available. The developers didn't really have to think about security, even though in the healthcare industry, security is a big concern. And that was all leveraged from the robust tool kit available in API Management. Taking that heavy lifting away from the developers so they could focus on functionality and we could focus on delivering the secure access they needed, was great.

It sets itself apart mainly because it's a bigger product and a bigger company, so it integrates well with other solutions that we already have on-premises. That makes it a lot easier for us to move people around, since they already have a basic skill set. That really helps. The support that we get from CA in general, including the talks, the books and the documentation that explains how to sell from a technical and a non-technical side, really benefits us.

We have recently implemented it so it is too early for us to say how this product has improved the working of our organization. We wanted it as a feature and capability for the organization so we have invested in it. In the future, it shall proceed in the direction of how we would like to shape-up our organization.

We have been able to accelerate our clients’ transition to digital organizations by using the CA API Gateway to rapidly expose legacy business services as RESTful APIs, adding industry-leading security to the APIs, and providing a Developer Portal that provides governance, control, visibility, and organization of the entire API stack. These features result in faster time to market, cut months off project timelines, and enable businesses to prevent from becoming disrupted by high-tech startups.

It's a great tool, but I wouldn’t say it streamlined anything. It does just exactly what we acquired for, which is to connect and manage data from our legacy system to the cloud and to mobile. We had some digital channel projects that required back-end integration and needed security on the gateway to handle the throughput that would be coming, so we chose API Management.

I mostly used it when working in the banking sector. There are many bank connections going on every day, especially during the holiday season, which can be kind of tough. We need to straighten the books, which can include how much money came in, how much money was lost, etc. If the information is not there, there will be a problem. We needed a program to keep track of the data.

This solution gives us an insight to the original view. It tells us how much data is there and it provides manuals to use it. So the technician office is there and it gives us some data. For the moment, we can change anything in the software, like enlarging it for example. 

It improved our organization because it gives the management data to discuss for the next course of action and it suggests what to work on, as the next thing.

I published APIs in the CA environment also. That's very good. I haven't done it in my workspace on a personal level, but it's a good thing. I have already published APIs with other solutions, but there is a bit of a difference and that is good for CA. CA is better than Apigee because CA allows you to make changes and is a little generous in terms of where to go with the project. It's good.

It's very good at supporting a large number of APIs or transactions. The transport of APIs is needed. Everything in CA is very easy for developers, because when a developer logs he can view it right away. With other systems, it isn't as easy. I like this. It's going up in the market.

Being a key partner of CA, the strong product has helped us make joint pitches to multiple enterprises and to implement an efficient API gateway for enterprises, enabling them to manage the end-to-end lifecycle of APIs.

The governance of the new business models generated by the APIs has been simplified and is improving the daily control over them.

We've got all sorts of threat protection in the API Gateway, from DDoS through to SQL injection and things like that. These are standard features that we use within policies that we drive out the Gateway.

We've got a security policy fragment that we know is consistent across all the APIs we expose via the gateway. Also, as it's a fragment, we can add to it at any point, as new vulnerabilities are discovered, which will then secure all the services/apis that use it. This gives us greater agility and confidence that our APIs are secure.

When we thought about the API platform as a whole, our intention was to provide the solution both for our internal customer as well as for our external customers. What we mean by that is we are a very geo-spread company and there are internal folks who also leverage the same services which are currently consumed by our external customers. So the intention when we thought about this whole solution and the future perspective was to have a single platform that caters the niche for both, without trying to deploy them in a very indifferent way. We have seen in other places and even in the past that you have a solution and deployment that provision for internal users and separately for external users. That was too much cost: maintenance and redundancy. We wanted to bring them together as a whole and that’s the aspect which we like the most using the proxy aspects of it and the ability to configure the different end-points. We point out based on the user base which end-point we hit on without a compromise in any of the scalability, performance and security aspects but at the same time using a single platform per se.

It provides us a needed level of security in restricting access for the user. It’s able to make multiple API calls while looking like it’s just making one.

It definitely helps a lot with the DevOps and the support. Reliability is one thing, and having visibility into who is using which APIs. 

Some of the performance matrix that API Gateway gives off - we monitor them via SNMP traps - and then we tie them into our monitoring system. You can actually monitor some of the latencies and some of the performance aspects of both API Gateways, as well back end services. So having that line of sight surely helps in terms DevOps.

We are still evaluating it, so I cannot comment much on this. 

It provides a centralized security mechanism so that we can route all our policies and all our traffic through the gateway.

Secure API exposure and driving Innovation through microservices.

It's separating web services versus web applications, single sign-on. I would say that is the main benefit.

The simple REST based APIs can now be delivered in hours which took days previously.

It allows you to much more rapidly expose enterprise services to front-end applications, such as mobile and web.

We implemented few Layer7 project to various organizations. Most of them just use it as a 'proxy' for policy checking. For example, limit the number of access attempts on specific page from the same IP for a specific duration.

Other clients use it for logic flow, to create a workflow integrated with the Australian government's MyGov framework, which is beyond just security checks.

It helps to improve customer satisfaction. When customers need to integrate with our platform, they are able to self-serve by using the online documentation and tool and then test their integration independently in a sandbox environment. Once the testing is complete they can request the switch to production.

It really benefits us a lot because, since we are maintaining financial information, personal identification information, we need to protect the customers' data as well as the clients' information. We can encrypt the payloads and decrypt the payloads and do SSL authentication. We can also store the files in the Amazon bucket with the encryption file.

We are a company with a rather complex process when it comes to integration of applications. Our expectation - we are only about to get this product into  a productive state so we are not using it productively at the moment - so the expectation is that it will simplify the on-boarding of either internal or external developers when they are using our APIs.

We use it to integrate various different customer and backend systems, in order to automate business processes.

The API Management suite for us is still fairly new as it's not as expanded as SiteMinder is. However, the potential for it to expand is still there. As an organization we can see that this is another one of those products that will be ubiquitous in the near future, just as SiteMinder is.

Organizationally speaking, it will fill a lot of the gaps where we are developing in new spaces, especially in mobile spaces, and it's going to be adopted globally in the near future in my prediction.

APIs can be developed to provide security. We can show them in one single pane of glass, such as the CA API Management API Developer Portal. It is there that we can provide the monetization for their APIs and what is happening on third-party applications, like Paytm or BookMyShow. 

Customers go to the portal and register there. It is there that they chose their APIs from a list. Based on the registration of the APIs, the customer will be charged.

Our customers will purchase these APIs and give to their application users. The functionality provided by the CA API Management tool is about the work framework, and the API Gateway also provides work functionalities. In the API Gateway, there are features called Solution Kits. These provides work protocol functionalities and the framework. 

In order to develop an API, we'll face so many problems: 

• What method we should use?
• What is the data it should return?
• If I give this API data to the browser, how will it be processed? 

There are so many problems from the perspective of designing an API. However, the CA API Management tool, along with the CA API Gateway, eliminate all our issues.

As an organization grow, you can use CA API Management for authentication purposes through the CA API Gateway. It allows for multiple identity providers with different Active Directories.

We have developed frameworks around this product set. It provides the ability to customize and has tremendous depth.

The frameworks are configuration driven, which gives the ability to implement micro-services architecture with ease and provides DevOps agility in terms of continuous deployment, etc.

I think it's protecting and exposing our internal APIs externally. We have a lot of different types of back-end technologies that use the APIs -- REST, UIs, and GUIs. So using the API product creates a single set of APIs, even though in the back-end they're much different.

It improved how we function in the following areas:

• Protecting all enterprise application data from direct access by virtualization.
• Transforming SOAP services to REST services easily on the gateway without impacting existing systems.
• Providing security for all API's exposed through API Gateway at one common location.
• Migration of APIs from one environment to other.
• Providing high availability with horizontal scaling and multi cluster.
• Managing the API lifecycle.
• Exposing enterprise data to the external world.
• Securing Mobile App communication using MAG.
• Integrating easily with other systems.

It has improved API governance, gives analytics to API performance, and provided abstraction to the solution providers.

I like the extensibility of it. It can do a lot of things. You can create little, custom Java assertions which you can insert into your business logic. This might not be covered by the commercial product out-of-the-box. 

• The API Gateway has allowed us to manage and maintain systems quickly, with great versatility, while solving problems in real-time.
• It allows us to keep clear traceability of the changes made in each of our APIs.
• A large number of security measures have been implemented which make data manipulation more reliable.
• As a SaaS product, control over some configuration elements and environments is lost.

It can be scaled, especially the current version. It can be scaled as we need. And it can be used in different regions. We have different data centers in the U.S. and Beijing. We use it on-premise, on-cloud, and it can be hosted and used at any place and scaled across the regions. That's the primary benefit we have seen; other than providing security and the performance.

What we had before, Forum, obviously was not reaching our performance requirements. This really helped us, because every API that we get from external or from internal goes through this layer first, and it should not be a bottleneck. That was the problem we had before. Now it's no longer a bottleneck. It's more like a throughput, this process is less than 10 milliseconds for any particular API. 

So the number of transactions that we are able to process per second and the number of instances that we can use are benefits. 

Even before microservices API gateway came into the picture, two years back, CA really worked with us and helped us to get hourly pricing, so that we could spin up, spin down instances as we need, like during Thanksgiving or Christmas. So the product, by itself, is great, and the flexibility that CA has given us out of this product is really great.

The API Gateway for us is now, or is about to be, our central one way in. We have many, many partners who resell our communications services. They provision those services through our systems.

Previously, we would just host it on a number of different application servers, uncontrolled if you like, not as secure as they should have been.

You probably don't know, 18 months ago we had a large security breach, which turned into a large issue with the national press. We now use the Gateway for that single point of entry for all of our API traffic.

We needed a way to secure our externally-facing services. Layer 7 was a lot more lightweight and its security chops were more apparent. For deployment, it needed the ability to go with a VM image because it was not going to be on-premise. It was going to be in a cloud offering in front of our commerce spot.

It improved the integration channel between partner companies. It also improved the time it took to onboard a new partner.

The benefit is maintaining the security of the APIs and securing the transfer volume of the enterprise for any business transactions.

CA is the first in the market from the time they acquired Layer 7. They deliver the best API Management solutions.

From 2012, our clients evolved a lot from API Management perspective after using CA.

We are able to expose mission critical APIs to the external world, monetize them, and generate revenue from them in the most secure manner.

CA also drastically improved the capabilities from Gateway, Portal, and OAuth perspective in the last couple of years. This adds more value to our API Management wing.

We have used it as the top layer in physical infrastructure architecture and made that available to mobile, iPad and desktop applications. Basically, it worked as a single point of contact for all applications via HTTP protocol as a communication channel. Underneath, it is aggregating a plethora of REST and SOAP services and connections to LDAP, AuthMinder, RiskMinder and SiteMinder for authorisation and authentication.

With it, we provided an enterprise solution for authentication and authorisation for all internal and external application in a quick and efficient manner using existing SOAP and REST services.

We use it for managing policies and that process is simple and easy to perform.

One of the main ways that CA API Management has improved our company is that we do not require a lot of people to work in developing new security code when they are programming for the APIs. They leave all the responsibility to CA API Management. 

In this manner, our developers can focus on just writing the code and on important business.

• Secure access to customer records – secured device, only access when in correct postal code area.
• Provide key, up to date information to engineers when engaging with customers.

The API gateway is a great solution.

• Standardization of our API deployment
• Improve security