Server Object Extension: read configurations at runtime

[SimonLeo]

I have a question very similar to this post: http://forums.arcgis.com/threads/72489-Server-Object-Extension-Location-at-runtime

my project has a requirement for the client to change some configuration values whenever they want. so we need to put these in a separate file, and make SOE read these values on-the-fly instead of compiling them together.

is there anybody who has a good way to make this happen?

i am wondering, if have a separate config file in the same folder as of deployed soe file then in development using current path to read config file, will this work?

not sure the way how SOE works. will the AGS host machine keep a copy of SOE file after user uploaded it via AGS manager? if this is the case, I may put the config file there.

but where to find this soe file at ArcGIS server machine? from Esri reference, it says "When you finish these steps, the .soe file is uploaded into the server system directory and the SOEs contained in the file are registered with the ArcGIS Server site.". which system directory is here?

sorry if any of above doesn't make sense. and appreciate any help!

[RichardWatson]

My problem is that I have SOE specific configuration information.  The way that I solve this is that when the user wants to change the configuration I redeliver the SOE package.  An SOE package is simply a renamed zip file which I build via software myself.  In that package I create a XML configuration file that I use.

Unless you are developing software only for yourself, you have to keep in mind that the SOE can be deployed on a ArcGIS Server site which has a large number of machines so having to find and update each one is problematic.

[nicogis]

Simon, I don't understand: if the user wants to change the configuration why don't you expose them how parameters of soe?

[SimonLeo]

first of all, thanks Richard and Domenico for your good suggestions.

re)Domenico: I was referring to the configs such as Connection_parameters to a ArcSDE GDB for example and other behind-scene configs. I don't think these stuff can be exposed as SOE parameters.

and the client they want to be able to make changes in configuration without having to ask us to re-compile/deploy a newer SOE for them.

re) Richard: I did a test this morning and found a path that SOE runtime can find a specific file. But this path is not same as of where uploaded SOE file is at ArcGIS Server host machine. I don't quite understand your words here 'ArcGIS Server site which has a large number of machines so having to find and update each one is problematic'. do you mean a distributed server network? so each server machine may have different environment so may cause inconsistent paths for config.txt?

[RichardWatson]

The type of parameters that I have are site wide and not instance specific.  For example, I don't want these to be exposed to users who are creating map services.

ArcGIS Server supports a scale out architecture where you have any number of machines which host map services.  ESRI refers to these as GIS Servers.  So you might have a web adaptor on the front end with say 25 GIS Servers on the back end.  In this type of scenario, you have to update your settings on all 25 machines.  In order to avoid that, what I do is to package the settings inside the soe file and then tell ArcGIS Server to update the soe on all machines.  ArcGIS Server is also responsible for dealing with any services that are running that use the soe.

You can do all of the above yourself but why not let ArcGIS Server handle it?

[SimonLeo]

Richard, I got your point now.

my case is slightly different. The original thought was just to have a set of function wrappers that call ArcObjects to do a bunch of things, such as spatial/attribute query in a GDB etc, then return the results to web UI. we don't need any MapService or related resources in this case, but since SOE currently can only be enabled in a MapService setting, we so created one with some test data.

this SOE is not for site-wise, but for some specific applications, such as the 'fake' map service we have to create in order to use this SOE. although each MapService can enable it, there is no interaction or communication between this SOE and the map service. we just want to call RESTful methods in SOE.

so I think manualy deployment is not a problem for this case. I just need to know where is the stable path to put a config file. also this path should be straight-forward if user wants to re-deploy this SOE, say, they re-installed AGS etc. such as where to get the path of deployed SOE file on a GIS server machine at runtime? for now, I can find the path of assembly but it doesn't look easy to find for the client...

but your suggestion is very helpful. thanks!

[nicogis · Accepted solution]

you can do it: you need serialize and deserialize your objects because in soe properties you store strings (you can create property page for use in the Service Editor dialog box in ArcGIS for Desktop: http://resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/0001/000100000nw3000000.htm)

For Richard: Ok I have understood but I unlikely that a user create a service without a minimal skill for do it.

with IServerEnvironment3 you can get info on users, path, property ect. http://resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/index.html#/Getting_user_and_role_...

[SimonLeo]

I think SOE property page is what I am looking for.

thanks!