I have a service callout in Apigee where instead of hardcoding the Url for the HTTPTargetConnection I want to use a variable for the value of the url.
Example:
http://{request.queryparam.url}
This is giving me a 404 Not Found error but if I hardcode the same value that is passed as a queryparam it works fine and calls the target service and return a response.I am not able to find any details on this in docs.Please help me out.Thanks.
This is potentially a bug.
Please attach a policy of your own in the target.xml request part of the application which assigns the target.url variable with your variable of choice. You can use assign variable or javascript or python as you wish for this policy.
EDIT:
What I answered above applies for target callouts. Not service callouts. To better understand the issue I request you to post the debug.xml in a pastebin or something similar.
Related
I have rest end point /admn_resource_manager.I have created a apigee proxy to expose this.
I dont want to expose it like this to others as I want something like /adminmanager.
Is there any way to map /adminmanager to /admn_resource_manager using Apigee.
end user would use http://someurl.apigee/adminmanager instead of http://someurl.apigee/admn_resource_manager
I explored KeyValueMapoperation and AssignMessage in Apigee.
I am not sure if these are the right option to implement map path.I didn't get any example for this either.
The way you would think to do this would be to use the Assign Message policy and use the Set -> Path element. But this policy isn't currently working as designed for rewriting the proxy's target URL. See the Assign Message Guidance for more details.
To rewrite the incoming URL to a different target URL you can use the Assign Message Policy to set the entire URL (target.url) in the Target Endpoint flow, or you can use a JavaScript callout to set it. I chose to use a JavaScript callout because it gives a lot more control when rewriting the URL.
Here is an example project on Github I put together for this you can use to see how I did it. It uses the swapi.co api as the target endpoint. This proxy uses the Assign Message and JavaScript callout policies to rewrite the URL. Here's some details about it...
Proxy Endpoints
Create a proxy endpoint for each resource you are renaming.
This is where you setup the Assign Message policy to set the variables for the new path suffix.
Assign Message Policies
Set on the PreFlow of each proxy endpoint to set the targetPathSuffix and appendResourceIdToUrl (if needed) variables.
JavaScript Policy
Calls out to the URLRewrite.js file to execute the js code.
Set on the TargetEndpoints PreFlow and executes on each request
Uses the variables set in the Assign Message Policies to change the target.url variable.
I think Apigee can do it.
When I was started Apigee I have learned and try to understand from the picture below. (I think it is describe the main concept of this platform)
From your scenario,
You can specify the URL that you wants client to call maybe someurl.apigee/adminmanager or something else
Apigee is a middle also known as a Gateway. When you received the request from client, you can manage whatever you want. Of course, including pass your client to other URL like someurl.apigee/admn_resource_manager . (You just assigned new url to that request)
Because I'm not an expert as well so, you this link below can explain you more information.
Link:Using Flow Variables
I am trying to migrate a legacy system to use artifactory. However I have two blockers:
the old scripts require PyPixmlrpc, which artifactory doesn't support
they also make use of upload_docs, not supported by artifactory's pypi implementation either
a smaller issue, the old scripts call register and they expect 200 instead of 204 http status code.
Would it be possible for me to write a plugin to implement this?
Looking at https://www.jfrog.com/confluence/display/RTF/User+Plugins I couldn't find a callback for when POST /api/pypi/<index-name> is requested.
If I can make
work for the methods we actually use, to just pretend it deployed docs and to respond with the correct status code I will be happy enough.
As you say, there is no plugin hook for the Pypi API endpoints. It would be possible to use the altResponse endpoint to customize artifact downloads, but then you would be restricted to GET requests with no request body, which is also not a good option for you.
I think the most viable approach would be to define a custom executions endpoint. With this, you can specify the acceptable method, read the body, and set your own response code and body. The main shortcoming with this is that you can't customize the path (it's always /api/plugins/execute/[execution_name]), but this can be worked around.
Execution endpoints can take params in the following form:
/api/plugins/execute/[execution_name]?params=[param_name]=[param_val]
Say your plugin takes a param path, which represents the API path your old scripts are going to call. Then you can set your base URL to /api/plugins/execute/[execution_name]?params=path=/, so that the API path is appended to the param. Alternatively, you can use nginx or another reverse proxy to rewrite the original API path to this form.
(Since you'll be using XML-RPC, I don't suppose you'll need to worry about any of this path stuff, but I'm including it anyway for completeness.)
Some issues with this approach:
Execution endpoints only allow String responses, so sending binary data in the response body might be finnicky. However, no such limitation exists with the request body.
If you need more than one request method, you'll need more than one execution endpoint. This means you'll need to use a reverse proxy to rewrite each method to a separate endpoint. Again, since XML-RPC just uses POST, this probably won't be an issue for you.
Execution endpoints can't customize response headers. Therefore, if your scripts expect a particular Content-Type or other header, you'll need to use a reverse proxy to insert it into the response.
I am developing an application that will serve multiple customer-organizations, each of them should be given access based on a fixed url. Example: domain/myapp/CustomerOrg1
Previously I always registered a new WAComponent-subclass for each of these entry-points. That does work but there has to be a better solution, I would like a single component-class to find out which URL the request uses (to then respond with the customer-org's homepage)
I tried:
registering a WARequestHandler-subclass; and it allows me to find out the full path (incl. /CustomerOrg1) but I am outside of any session and don't know how to get into one.
registering a WAComponent-subclass as /myapp, and it works in that it also handles /myapp/CustomerOrg1 automatically, however when I try to find out the URL used (by self session url inspect) it claims to be only the base-url (/myapp).
Try
self requestContext request uri
and if you are not in a component but any object you can do
WACurrentRequestContext value request uri
Please be aware that the uri you get in the answer by Norbert is in a production environment a value that has already been processed, and possibly modified, by your (Apache/nginx/etc) webserver responsible for static content and load balancing.
Is there a way to get the server url (ex: http://www.myapp.com:8080/applicationFolder) without having access to a Request object ?
I need the url at aplication_start and in some classes where the Request object with all the goodies is not available.
note: I know that getting the application folder can be done using
VirtualPathUtility.ToAbsolute("~/");
HttpContext.Current.Request is a static property that always returns the Request object currently executing for the session.
I think all you need a custom solution to know when first request is made after application starts, and then you can send any email you want.. this is the similar problem with solution here http://weblogs.asp.net/reganschroder/archive/2008/07/25/iis7-integrated-mode-request-is-not-available-in-this-context-exception-in-application-start.aspx this do first initialization check in BeginRequest event.
There can be many different addresses all pointing to the same ASP.NET website, like using IP address or name. There might be more than 1 DNS name pointing to the same ASP.NET application. Therefore, HttpApplication, the parent class of Global, does not know which URL a visitor will use. Even IIS doesn't know. Therefore, you have to wait for the first request and then check in the request what URL the visitor uses to access your site. Something like this:
string baseUrl = Context.Request.Url.GetLeftPart(UriPartial.Authority);
One has to use Context to get access to the Request during Global.Application_Start, because Global.Request is not initialised yet.
I am developing a RESTful framework and am deciding how to handle an unsupported verb being called against a resource. For example, someone trying to PUT to a read-only resource.
My initial thought was a 404 error, but the error is not that the resource cannot be found, it exists, just the user is trying to use the resource incorrectly. Is there a more appropriate error code? What is the most common way in which this situation is handled?
Is it that you simply don't support a certain verb ie DELETE? In that case I'd use the following HTTP response code if someone uses a verb you don't support.
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource;[2] for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource. [source]
I don't think you would receive a request to your app at all if the incorrect verb were used (but that probably depends on which specific technologies you're using on the server side).
To be more helpful to potentially confused client connection attempts I suppose you could create a stub endpoint/action for each commonly incorrect verb, method combinations and then send back a friendly "use {verbname} instead for this request" text response, but I'd personally just invest a bit of time in better developer documentation : )
You could also seamlessly redirect to the correct action in those cases...