Layer7 API Management

Why the CA API gateway does not permit to use a script language like Java Script or Lua to code the policies instead of the current approach? A script language would be way better, you could apply design patterns and the code refactoring would be easy...

The current design methodology for policy authoring is an artifact of inertial. It has always worked this way and continues to do so until a better solution is designed. I would be more than happy to take any input or thoughts on how to improve our policy authoring process and provide them to our engineering and product management teams. Can you elaborate upon the idea of leveraging JS or Lua to enhance policy authoring and management? Can you provide any examples of existing tool sets that use these scripting languages in a similar manner?

If you could code your policies using an script language like Lua or Java script or even plain Java code it would be easier to mantain, the code could be saved on a repository, the user interface to code your policies would be really easier as you are dealing with pure text and not components..

The better example i can give to you about using a scripting engine is games, they use a lot of scripting languages to deal with stuff that can change over time.

With the current approach, using the Policy logic(All assertions... at least one...), i found really difficult to implement complex logics that would be really easy with a programming language. With a programming language, you can control your variables scope, you can code better and modular code much better than the current fragment approach and even apply very known design patterns.

Another thing is people who already know Lua or Js would not have trouble to learn.

I found really difficult to deal and mantain policies with more than 300 assertions(the CA gateway interface gets slower, etc)...

I really miss the flow control, variables scope, etc of programming languages on API gateway.

You dont have encapsulation with the current approach, you cant mock a fragment without breaking everything.. Ive seen people changing an assertion in a fragment and breaking the entire apis...

While it is unfortunate that it occurs--"Breaking entire APIs" is not unique to the Gateway. Bad commits happen in policy and in code.  As such, the Gateway comes with a very well-developed set of tools to track issues caused by this. We provide revision history to allow immediate reversion of changes. We have policy differential tools that illustrate differences. We have a deep auditing system in place to track changes.

Service policies and policy documents on the Gateway are XML files, at the end of the day. If you export a policy from the Gateway or copy-and-paste it into a text editor then you will see that a policy is a large amount of XML. Policy assertions are pre-written blocks of XML then are filled in based on the UI components. The XML code for an assertion is essentially a template that is modified by the UI components. For example: The Route via HTTP(S) assertion starts as a template block of XML. An operator or administrator adds the assertion to the policy. The template is modified based on the user input--such as routing URL, preemptive credentials, or header and parameter customization. The assertion is then saved and the corresponding XML is saved to a document.

This model was actually a significant strenght of the API Gateway. Legacy XML gateway and web security platforms required that the policy author be familiar in many complex WS-Security technologies and be capable of writing XML by hand. Writing XML by hand can certainly be expedited by a development environment but it still required specialized programming knowledge. A significant gain was provided to our customers by allowing people to write policies even if  they were not fluent in software engineering. The Policy Manager and the paradigm of policies has never been associated with free-form coding--by design.

To that end: The policies are XML and XML can be source-controlled. We have tooling in-place that allows administrators to integrate API Gateways into existing source code repositories and versioning systems (such as ClearCase, SVN, or GitHub). You can use the Gateway Migration Utility to facilitate this effort and export whole configurations, folders, services, and other configurable items of the Gateway. Hopefully that helps with the control and versioning element. If you need further assistance with using that implementation then I would recommend opening a new issue with CA Support.

With regards to conditional logic: There is certainly room for growth in that area.  I have authored an article that gives a bit of primer on authoring conditional statements in the Policy Manager. It can be found here: Creating conditional statements in the CA API Gateway Policy Manager. This document is currently pending moderation so it may not be immediately available. Please check back later if it is not currently available.

We also have several development incidents open with respect to improving the policy logic flow of the API Gateway with respect to conditional statements:

SSG-4884: Allow "At Least One" and "All" folders to be toggled. This would allow an existing conditional folder to be switched between At Least and All, dynamically

SSG-8425: Allow "One Or More" as a composite conditional assertion. This would allow an arbitrary number of assertions to pass in order to succeed.

There are many others out there and I can happily find more if you are interested. Point being: We recognize that the flow of policies can become very complex very quickly. We've also made a lot of progress in developing the Policy Manager into a more robust IDE instead of just a drag-and-drop interface for the Gateway. Functionality such as the service debugger, revision histories, and having multiple concurrent tabs were all designed with the intent of catering to the broader software engineering community that use our product.

Thats good to know. But i still think that a programming interface to policies would be great.

Maybe just a tool that converts the programming language to the XML that the gateway use.

But, it would be really nice to program the gateway using Lua or JavaScript.

And of course... Maybe implement ctrl + Z

Im coding a fragment at this moment with more than 100 assertions, it takes 4 seconds just to save.

And thanks for the article

Glad to help! If you have any other questions on this subject then I would request that you open a new issue with CA Support. It would be great if you could mark this question as answered if you feel it has been satisfactorily addressed. Thanks!

You awnsered my question.

But im still in trouble with the current approach that CA uses.

Im coding a fragment that call over 10 services, process XML, JSON and stuff.. Its really hard to deal and to create the necessary logic using the assertions.

Heres a exemple, i have a part of the business logic that means that i have to return of the fragment to the main API.

In a programming language it would be a simple return over functions.

With the assertions logic, with nested assertions, nested foreachs its really hard to get back to the main api.

Everyone i know that work agree that a scripting approach would be better

With a scripting approach it would be easy as code in PHP.

For example, i\m working on a fragment with over 150 assertions at this moment, its really lag to move the folders and assertions on the interface...

Unfortunately, there is no change or improvement that can be made in the current iteration of the product. If you would like us to submit an enhancement on your behalf then we can open a new request with the API Management support team. I do not have your contact information so I would recommend that you send an email to API-Support@ca.com in order to open a new issue.    

Thank you Eric.

I don't know if you are in contact with the development team, but if you are or any CA enginners are reading this, could you please consider a scripting approach?

Hi  Mahcoisa

Raise an idea on this community, the product managers will review and other customers can vote on the enhancement to raise it's profile. 

Regards

Christopher Clark

CA Support