Latest Contributions by KevinHibma

I have also noticed that when publishing my scripts, ESRI takes it upon themselves to REWRITE my code in the service directory, which I have found actually causes some of my script to FAIL as GP services....WHAT!!!!!!! That is a HUGE no no to me. DO NOT CHANGE MY CODE!!!!!!!!!!!!!!!!!!! Please fix this in SP1, as I am extremely disappointed with the change! The only code change we make to scripts is the insertion of variables for data (and sometimes sql expressions). Since part of the new publishing processes is a mechanism to ensure all data required by the service can be found and is available, we need to update the paths. If you're encountering an instance where we didn't update the paths to data correctly, or didnt copy data over that was required then I'd be very interested in fixing it. Is there any chance you can share the tool/script/some data with me? Unfortunately based on timing, we're getting SP1 pretty locked down. I'd need to be able to reproduce the issue here in house and get a fix for it before Friday to have any chance at SP1 - else it would probably be next service pack. If you can share, feel free to email me directly at [email protected] ... View more

Are you trying to remove the layer from the mxd or simply the layer in the list from the python list ? If the first, I think you want to use RemoveLayer: http://resources.arcgis.com/en/help/main/10.1/index.html#/RemoveLayer/00s300000039000000/ If you simply want to modify lists built in Python, the ListBrokenDataSources returns an actual layer. So your code is trying to remove a "layer" from the list. In other words, because the ListLayers and FindBrokenDataSources command dont return exactly the same thing, you cant remove the layer in that way. I think if you force NAMES into the list and work directly with those, it'll work. Is this applicable for your workflow, having a list of layer NAMES? ############################## # LIST ALL SHP IN MXD list = [] df_list = arcpy.mapping.ListDataFrames (mxd) for df in df_list:     for fc in arcpy.mapping.ListLayers (mxd, "", df):   if (fc.supports("DATASOURCE")) and (fc.dataSource.endswith(".shp")):                     list.append(fc.name) print("List created") ############################# # REMOVE BROKEN LINKS FROM LIST brokenList = arcpy.mapping.ListBrokenDataSources(mxd) for broken in brokenList:     list.remove(broken.name)     print ("Broken data removed from list") ... View more

Ok, since you know exactly what they want, you have 2 options (that I can see anyway). Once you get your select working, you're done - have them parse your JSON. 🙂 Or, if you're in a helping mood, take the suggestion from Chris which uses a cursor, grab the required IDs and build them into a string. Make the output of your service just that - a comma delimited string. ... View more

I just skimmed through this thread and the questions proposed by Chris a couple posts up "what are you doing with this list, what program will consume this list" I think have to be answered before you move forward. The cursor is approach is fine, but is it really needed? I can't envision a cursor result as output to a GP Service that would be usable by a client (note I say I cant imagine, not it can't be done).... From your very first post you looked to be doing select on a feature and want to pass that result. Well regardless of it its a table, or featureclass, you get attributes back (I assume that is what you're ultimately after) from further posts. You did mention JSON. So, if you Java developer says "sure, I can take a JSON list and get what I need from it".... you're pretty much done. Tell him how to connect to the REST end point, execute your service, load the output into some sort of JSON object and parse it. Of course you could do them a favor by trimming the amount you output by only returning a table/features with just the fields they need (else they might be parsing more then they want to). As an example, I used the Copy Rows tool, published it, and the output when requested as JSON comes back like: {       "attributes": {        "OID": 1,        "LABNO": "C-117267",        "CATEGORY": "NURE",        "DATASET": "NURE Coastal 98",        "TYPEDESC": "STRM-SED-DRY",        "COUNT_": 118,        "PB_ICP40": 12      } Hopefully this helps, you're on the right track, I just think you need to confirm with your java developer what they want, or what they can use. ... View more

No, my apologies, I'm not aware of any workarounds to the GUI in terms of hiding their password. Thinking out loud - you could have the script read from a textfile on their harddrive, and they place their password in there. Of course theres nothing secure about that.... ... View more

If you havent seen this topic, give it a once over to see if anything stands out with what you're doing in your script. http://resources.arcgis.com/en/help/main/10.1/index.html#//00570000007r000000 Could you email me your script? I'd like to see how you put it together and why the analyzer thinks you have project data that it cant find. khibma[@]esri.com thanks ... View more

If its a hardcoded list that doesn't need to change based on other parameters, you dont need to use the Validator. On the Parameters tab of your script tool, add a new input of type string. For its properties, chose Value List for the Filter. In the window that opens, add your strings one-by-one. ... View more

Hmmm strange that you can package it, but not turn it into a GP Service. It should be going through the same code paths to do both of those actions. Since it says it failed on consolidation, it sounds as if you are not using a datastore (you're copying data out of SDE, putting into an fGDB and moving that to Server - well thats what happens when you dont use data store). Could you register your SDE connection with the Server and try to publish again. Does that succeed? If not, you said you have been able to successfully package it. Could you send me the package and I'd try your workflow here? khibma[@]esri.com ... View more

Hello, The encrypted string parameter you're using is meant for tools which except an encrypted password (like our Create ArcSDE connection tool). We've been having internal discussions about this particular type of parameter, something like a "hidden string", where in the UI you'd only see the ****, but the tool would get the actual string somewhere in the code and deal with it (in your example, authenticating an STMP server). To answer your question, we dont have anything that will do what you want (hide the password in the UI), but the use case you outline below is helpful as we evaluate a new parameter type for a future release. Thank you. ... View more

Tool layers have been deprecated at 10.1. The workflow for publishing a service which uses layers (such as clip and zip) has changed. In terms of a workflow that makes sense, the changes are for the better: you no longer "publish a map to get a gp service".... Check out the updated tutorial for clip and ship. It should explain everything you need to know for publishing layers: http://resources.arcgis.com/en/help/main/10.1/#/Clip_and_ship/005700000073000000/ If you want more information on the workflow for publishing layers in general (previously tool layer to get at those layers), see the migration topic: http://resources.arcgis.com/en/help/main/10.1/#/Migrating_geoprocessing_services_from_version_10_to_10_1/00570000004v000000/ ... View more

Please let me clarify some statements: When I say best practices, I mean best practices being suggestions, and the addition of trapping for the things which prevent your service from working. Best practices appear as warnings and messages in the analyzer and others are the errors which wont allow you to publish the service. Warnings and messages are something you (the service publisher) can chose to ignore or implement. We don't force these on you. I understand your concern with re-running and adding 30 tool executions into a task. Honestly, throughout beta nobody came to us with more than 3 or 4 tasks per service presenting a concern regarding running this many tools. To me, 30 seems like a lot of tasks on a single machine, but if you're deploying that many then you must have the system resources to deal with that many running instances. At this point all I can do is offer you some suggestions to reduce the time it takes to republish 30 tasks. Hopefully you can make use of one of these in your publishing: 1) In the Geoprocessing Options in ArcMap (Geoprocessing > Options), you can set Results Management to "Never Delete". With this setting, run every tool you want to publish, you'll get a result for each Save the MXD. Anytime you want to republish the service, you simply need to open that MXD, run the updated tool, and then put together the service with a combination of old/new results. >This method is also handy as if any data required for the service has gone missing, the analyzers should catch it. 2) Go to Windows  > ArcMap options > Sharing Tab > check "show file location when saving draft service definitions" Run all of the tools you want to publish (you'll get a result for each) Get into the Service Editor by sharing a result as a service Add all your Results into the service Click the "x" on the service editor, and say YES to saving a draft. Note where the draft file gets saved to. You can re-open these and add or remove results from it later (when you need to update). Note: The .SDDRAFT files act more like pointers, so if you start moving tools/data from where they were when you originally saved, you could break references. 3) For 10.1 sp1 we're working on a pythonic (arcpy) way to publish gp services. It is early in the testing and looks good so far, but till its 100% I can't guarantee it'll make sp1. In short, you could write a runner or execution script to power you through the publishing process. The script calls each toolbox/task, runs it, assigning each to its own result object. You take each result object and pass it into arcpy.GPCreateSDDraft([list of result objects], , , ) - new function, then Analyze it, Stage it into a .SD, and finally Upload. This entire workflow has been well documented and exists for Maps. Like I said, we're working on it for 10.1 sp1 in terms of GP. Hopefully it'll come together like we want. ... View more

The idea behind publishing a good result, is that because it ran successfully in ArcMap, it has much higher odds of being successful as a service. It makes more sense to do the dev/testing inside ArcMap with a local tool than it does to publish a service and modify that. Additionally by publishing a result, we're able to help enforce best practices and modify tools/scripts/models that otherwise wouldn't have published successfully. Once something is a service and you modify it, we have no way to help with best practices or warn if something isn't supported. When you do all your dev work up front and publish the result (hopefully you only need to publish once), we're able to tell you what might be wrong with it and suggestion action. Well I dont really suggest this, if you're only making minor edits to your script, you can modify the script which gets moved to the Server (understanding that these edits dont persist back to your original script). You'd find the script powering your GP Service at: C:\arcgisserver\directories\arcgissystem\arcgisinput\<service name>.GPServer\extracted\v101\<original folder that held toolbox name> ... View more

Do you have the 64bit client libraries installed on the Server? http://resources.arcgis.com/en/help/main/10.1/index.html#/About_registering_your_data_with_the_server/015400000505000000/ ... View more

Are you using 10.1? (I ask because I think I remember the max size being different in 10.0). For 10.1, I believe you're well within the file size limits. I'd give a read on these topics, hopefully they'll help...maybe your max size is turned down? http://resources.arcgis.com/en/help/main/10.1/#/Large_dataset_upload_and_download_considerations/00570000005v000000/ http://resources.arcgis.com/en/help/main/10.1/#/Advanced_properties/0057000000m1000000/GUID-17815A98-2756-486F-AC2D-22672E0FCA28/ ... View more