Running Parameters Against an OpenShift Template Through the API - openshift-origin

I'm developing a custom interface which will integrate with OpenShift Origins. At the moment, I have templates which I wish to instantiate. I know I can do this by running the template against the /processtemplate end-point. However, the only way I can find for setting the template parameters is to iterate through the parameter list and overwrite the fields manually.
Is it possible to send a parameter list, and have OpenShift run it against the template, or is this the only solution?

We do not have something like that today - it might be exposed in the future via a /templates/foo/process endpoint supporting form post, but we were hesitant in case we wanted to expose more complicated parameter values in the future.

Related

How to implement api versioning?

I have an web API application that will serve many clients at different times of release and now i need to implement a versioning. Because the API code will be constantly updated and API users will not be able to instantly change their API. Well, the standard situation is when you need to introduce versioning in general. I'm finding a way to organize it inside my API. It's clear that it will not be different folders with an application on the server, conditionally called app_v1, app_v2, app_v2.1, etc., cause this is duplication, redundancy and bad practise.
It's look like will be one application, and in the controllers at the code level there will be a division of the logic already, like If(client_version==1) do function1() else if(client_version==2) do function2(), etc. It seems that git supports tags, this is something similar to versioning, but because all supported versions of the application need be on the server at the same time, this is not about that. how i can realize an architecture in this case?
There are many well-known ways to use API versioning to make code work with older versions. (backward compatibility). The general purpose of API versioning is a way to make sure that different clients can use different versions of an API at the same time. I've seen several ways to do API versioning, such as:
URL Path Versioning: In this method, the number of the version is part of the API endpoint's URL path. For instance:
https://api.example.com/v1/assets
https://api.example.com/v2/assets
URL Query String Parameter: In this method, the version number is added to the API endpoint's URL as a query string parameter. For instance:
https://api.example.com/assets?version=1
https://api.example.com/assets?version=2
HTTP Header: In this method, the version number is put in an HTTP header, like the Accept-Version header. For instance:
Accept-Version: 1
Accept-Version: 2
If you are using dotnet for you project I would like recommend to standard library for that recommend to check this out. Or you can find solid materials in term of WebApi Versioning following link by #Steve Smith.
There is another answer.

Is possible to make the options of properties dynamic in business template editor of WSO2?

Context:
in Wso2, to make Siddhi apps dynamic, one uses business rules.
This business rules are created from templates like this:
Rule templates have some properties for each attribute. In this properties there are options to make a list of possible values for attributes.
What I wonder is how to make these options dynamic, like calling from an external API or from the DB.
We are not supporting this feature for now in Stream Processor. You can request this feature by opening an issue in WSO2 GitHub repository.

TYPO3 - Insert api medipim

I want to call products on a web page via the api of Medipim. I have never done this before and I have never worked with TYPO3.
Therefore two questions.
In which (config) file do I place the authentication (I have an ID and secret key) and what exactly does that code look like?
When I want to call up the products, how do I use this in the TYPO3 page environment? Do I have to choose a html page or can I just enter it in the TYPO3 editor on a page?
Documentation: watch
You probably need an extension which converts the data you get from medipim to HTML. I Expect you get information as JSON, XML, or CSV.
As you won't publish your access code you probably will not use a javascript call from the browser to access the API, then you need some PHP.
Using PHP in TYPO3 is done in extensions. You should learn about building extensions in TYPO3. As a healper you might use the TYPO3 extension "Extension Builder" (=EB). As you have no local records you only need the extension frame with just one plugin from the EB.
Depending on your usage (will an editor select products from Medipim (option A) or should the visitor be able to select products (option B)?) you need a plugin with an option to insert desired product identification for BackEnd editors or just an input mask.
you can configure your plugin with typoscript so an integrator can enter the authentification information just once.
For option A you need to enhance your plugin with a field for the product ids.
keyword: flexform
for Option B you need a form.
Then you need to display the product information you get from the API. provide the returned data in variables and use Fluid templates to get a nice display.
Without any knowledge of TYPO3 this will be hard work and a lot to learn. The other possibility: hire an experienced TYPO3 developer and let him build this extension for you.

Adding licence field to WSO2 API in API manager

I have the need to add a licence field to the APIs published by the API manager.
It does not seems to be any extension point beyond the api.rxt file in the resource folder.
If I modify the file and run the application the carbon app correctly show the added field, but nor the publishe nor the store are able to get the field and there is no way to get it also with REST APIs since it calls a method of a class that (in later versions) outputted fields positionally.
Is it possible to add the field, without running the risk of crashing the API Manager?
Which is the correct way?
Thanks
This change cannot be done without modifying the code. When an API is created from the Publisher app, it gets stored in the registry. The api.txt you modified, only defines the structure of this stored artifact. It may add a new field to the artifact, but to correctly populate that field, you need to modify several methods in APIProviderHostObject and APIProviderImpl + several Jaggery scripts.

Programmatically accessing a Sharepoint list at runtime (without creating a service reference at design time)

I'm creating an app that will be configurable by the end-user to access SharePoint lists, on various different SharePoint sites, that are entered by the user.
All of the examples for reading SharePoint lists I've come across online are of the form:
Open or create a Visual Studio
project.
In Solution Explorer,
right-click the References node, and
then click Add Service Reference.
In the Address box, type the URL to
the target site and append
/_vti_bin/ListData.svc. For example,
the address for the site
intranet.wingtip.com would be
http://intranet.wingtip.com/_vti_bin/ListData.svc.
Change the default name in the
Namespace box from ServiceReference1
to something more appropriate, such
as WingtipSite.
etc, etc, etc
This method creates proxy classes within your project based on the specified server reference. However, in my case, the server/site is not known at design time, only runtime by reading the sites/lists specified by the user. How would one go about doing that (reading the list via http://intranet.wingtip.com/_vti_bin/ListData.svc, but at runtime only)?
Note: I am making this call from a different machine than the one running Sharepoint.
There are a couple answers.
If the lists schemas will be consistent across all the sites you are querying, you can still use the generated proxy. When you create the DataContext, you just need to pass in the URI to the ListData.svc for the site chosen by the user.
If not, then you can use an ASP.NET WebRequest with an appropriately formatted URI and parse out the ATOM or JSON response that comes back.
For more information on using the REST APIs, check out this talk from the 2009 SharePoint Conference
http://msdn.microsoft.com/en-us/sharepoint/ff462048
You can set the URL in your proxy class at runtime with the Url property.
SharePoint does not provide a proxy class for their web services. Therefore it's not possible to set the url at runtime. WHat I have had to do is add 2 service references and then paramaterize which one I will access. I use a config setting to determine which one to access. If the site name changes or list changes, then I need to remove the references, re-add them, recompile and redeploy. There is no way to change the SharePoint site/list at runtime. Have been searching for 3 days for an answer. Microsoft does not know how to accomplish this.