Alternative to Site Properties for an Extension

Alternative to Site Properties for an Extension

We are looking at options for how to configure (rather than hard-code) the endpoint used by our services extension, and have come to a dead end.
The endpoint is static, set for the environment, and will (almost) never change. It makes no sense to have to pass it to the extension on every operation call (there will be hundreds). So, want to be able to read it from somehwere in the extension.
Options Considered:
1. Get Site Properties of another eSpace directly from within the extension? Is there an API that allows this? Seems unlikely ...
2. Store it in the database. But it seems an Extension's entities are only intended for access to non-outsystems databases (we don;t currently have direct access to the database, as its a cloud deployment).
3. Store it in a file. Found FileSystem in the forge, but have no idea how we are supposed to configure the file access, or what location to use (its a cloud deployment, so no direct access to the servers).
We can probably persue options 2 and 3 with Support, but want to know if anyone has any other bright ideas.
Hi Dan,

One thing you can do to accomplish your use case is to create an action that wraps the extension call. That way, the extension will still receive an endpoint as an input parameter (from a site property), but it will be enclosed on an action that will be then used to perform subsequent calls to the extension, without having to set the endpoint on each one.

Please let us know if this is a soltion that works for you.

Nuno Parreira
Hi Nuno,

Thanks for your reply. But, I think you have misunderstood me (or I have misunderstood you).

We do have a second layer in our architecture with an Action corresponding to every service operation Action in our extension, thus it can pass the Endpoint as an input parameter, using the Site Property declared in that eSpace, exactly as you describe. All eSpaces that then need to call the services use this eSpace, not the extension directly. What I am trying to avoid is having that input parameter on all of those hundreds of wrapping actions, as its going to be the same for all calls in any given environment. 

And for clarity, this statement "operation call (there will be hundreds)" means there are hundreds of service operations that we need to expose, and we have already wrapped most of them without the Input Parameter, so also trying to save a little work with an elegant solution.

Hi Dan,

I believe Nuno's suggestion is actualy the best approach.

One other way of doing would be in your extension module you could create an action that would receive the endpoint and store it in session and then on the other actions that call the service you'd fetch the url and assign to the value.

But this would also force you to change all the actions that expose the service operations and the wrapper as well so I don't think you'd benefit much in terms of effort necessary to change.

You could expose the site property in the eSpace through a webservice, and consume it inside your extension.
Not saying that is an elegant or performing solution, but it accomplishes what you want. On the other hand, you'd have to hard-code the webservice url, or use that one as an input parameter...

Hi all,
We have a solution - and like all good ones, its rather obvious once you find it. Its just a variation on Nuno's.
The endpoint is stored in a static within the C# extension (I did not make this clear in the initial post, sorry). So, we only need to set it once for each 'session', and it remains in memory. Not sure for how long (my test had it still set after ~30 seconds), but that wont be a problem, because what we are doing is setting it via an InitialiseEndpoint action inside each wrapping service call actions. I.e. in Nunos diagram above, before calling the service operaiton action in the extension, it first calls the InitialiseEndpoint action of the extension, passing the Site Property of the wrapping eSpace.
This avoids any need for extra parameters on all of the already coded extention actions, or the wrappers. Adding this call to all wrapping actions is still not quite what I wanted, but it far less tedious, and seems to be the best approach.
BTW: there are downsides to using a File (gets a bit complicated in a farmed environment) and the database, so these 2 approaches were discarded.
Thank you all for your input, regards,