Get Table activity "Table Id" input to use either "id" or "title" key for lookup
Not planned
Currently, you can have Workflows lookup a layer by the "title" key and return the matching layer from a Web Viewer app using Get Layer. If you want to retrieve a table from that same app, you have to use Get Table, which only accepts the "id" value, which is a unique ID generated for each layer added to a Web Map. This ID is not difficult to acquire, but the problem is that if you remove and then re-add the table at any point, the ID will change, thus breaking your Workflow. It would be extremely helpful if you could have the activity lookup the table the same way the Get Layer activity looks up a layer. I have reviewed the output of a Get Table activity and have noted that "title" is a key in the output and in reviewing the JSON of a Web Viewer app, I noted that "title" is also a key in there as well, with both values matching when referring to the same table. Please consider this for a near future update.
-
This was deliberate to make Get Table easier to understand than Get Layer. Different viewers define layers/tables in different ways and we found that the different types of search happening made it complicated.
0 -
Randy Casey totally agree. Even if Get Layer and Get Table need to be separate activities, they should function the same way. I'm also trying to avoid breaking changes when a layer is altered. Have you or Ken Lyon found a workaround? I suppose one could dive into the Javascript, filtering layers by the title property and retrieving the id. But...I'm not a Javascript expert and also don't know what ramifications there are for using Web vs. Mobile if it did work.
0 -
David Flack No I haven't. But to further add to the confusion here, when using the exact same Activities in Mobile, you are required to use title for Get Table...that causes a lot of extra work when porting a Workflow from Web to Mobile or visa versa. It would be so much easier if the Activities were consistent, and this isn't even the only Activity that works inconsistently between the two platforms, so trying to tighten up the consistency in Activities like this would help application creators like myself.
1 -
Yikes. I decided to "parameterize" the layers in an external workflow, add them to a collection, and pass it back to the main workflow so I don't have to touch my business logic. That's going to get uglier when we move toward mobile.
0 -
David Flack as I mentioned, this is not the only issue between Mobile and Web. There are many activities that have very subtle, but nonetheless application breaking, changes (think accessing nested objects and/or values within activity results). I just now am finishing up a Mobile app that has a parallel Web app. I had to build parallel Workflows that perform identical functions, using the nearly the same activities because of the differences in how JS and .NET translate between each other when a JS Workflow is read into the Mobile .NET runtime versus straight JS implementation in Web. I wound up building the Mobile Workflows first, since they were the most challenging, then cloning them and modifying for Web, as Web was much easier to debug. Even then, it took me several days to find and fix all of the broken activities. When you plan out your first Mobile app, I would highly recommend tripling whatever timeframe you estimate for it, because many of these differences are not well documented and only become apparent once you start using it.
0 -
David Flack, Randy Casey
Thanks for your discussion on this topic. It's an ongoing challenge to strive to make the TypeScript and .NET versions of Workflow as consistent as possible. One big challenge for me is that I can't easily "fix" one to match the other without also breaking existing workflows that rely upon the existing behaviour. In the case different property names on an object we could perhaps add some aliases to maintain backwards compatibility, while also adding consistency. In the case of nested objects, though, this could get quite complex.
I'm curious about the comment regarding the debugging of Mobile. What would you say is the main thing that makes it harder to debug?
1 -
Ken Lyon Thank you for taking the time for this discussion. I know being in development can be very time intensive, so hearing from you is appreciated. Regarding debugging in mobile: there isn't one main thing that I can pin down that makes it challenging. Sorry I don't mean to dump on you, and I hope this doesn't scare you away, but these are real pain points I have experience just w/in the last 3 months and I feel the product would be so much more enjoyable to work with if these could be resolved or mitigated in some way.
Depending on the platform you are debugging on, the debugging console can be painfully slow and unresponsive, as I have seen when using VertiGIS Go on my Surface Book 3. I can run a workflow and debug it about 4 or 5 times before I have to completely close VertiGIS GO and restart it, as the debug console will be so slow that I cannot scroll up or down without having to pause to wait for it to catch up. Or when opening a debug line, it take so long that sometimes I click it and think it didn't take and I click again, only to have it open, then close again. I try to mitigate this by clearing the console after every session, reloading the application even when I haven't made any changes to the workflow, and exiting to the VertiGIS Go home screen. When using the iPad, the debug console is way more responsive, but I notice that after about 5 or 6 workflow debugs, VertiGIS Go crashes to the iPad home screen and I have to relaunch.
And then we get to the debug lines. Again, sorry for the dump session, but I feel these are real issues and they have caused me a lot of frustration. The dev console in a web browser is so great for debugging because everything is right there: every input/output opens in the same screen so you can actually compare in real time without having to open a line, review, close it, open another line, review, close, lather, rinse, repeat... Also you can filter for an Activity, open that activity while filtered, then unfilter and find that activity already opened and then look into adjacent activities more quickly. When you are combing through hundreds of debug lines, being able to find related and adjacent activities in this manner is incredibly useful, but you can't do that in the mobile debug console without adding logs to flag certain activities that you need to find, but only after you've determined that those activities need to be flagged. This slows down the debugging process, especially when the debug lines are not labeled or identified in a way that makes them obvious which one is the result set, which is the second one, I know, but the display can get confusing sometimes.
The debug lines for forms is nearly unusable. Yes you can get the result, which is important, but state is critical. I have learned that if I embed a foreach in every load and change event (with a log that provides the key value so I know which form elements is being returned as it iterates through the state), I can approximate the results I would get in the dev console in a web browser. Having all these extra processes requires extra resources though and slows down my workflows, but it's a sacrifice I have to make in order to debug properly. Doing this also adds dozens of additional lines to the debug console, making it slower and more unstable at times.
Again, I appreciate the time you are taking to listen and I hope I am not imposing upon your invitation to discuss this. But please know that I really want to be able to use Mobile in more of our application builds, because I do see and get how useful this platform is and I feel I could really make some great tools for our staff using Mobile, but because of the frustrations I have experienced, I feel I need to take a measured approach in creating mobile applications in the near future. I really hope that some of these items I have mentioned here and the previous comments can be addressed so that I can recommend more uses of mobile in our application needs and requests. Thanks.
1 -
Just wanted to add my vote here.
Finding a table by name should IMO be a no-brainer. The webmap contains both the table's name and ID, so I don't really see why it couldn't be done. The way it works now, the Get Table activity is actually harder to understand than Get Layer, not easier.
0 -
I'm also following Berend and adding my vote.
I spent many hours trying to figure out what I had been doing wrong with the Get Table activity. I combed the forums and reviewed the help documentation to no avail. The help documentation states “To find the table's ID for a workflow that will run in VertiGIS Studio Web, VertiGIS Studio Mobile, or Web AppBuilder, open VertiGIS Studio Item Manager, find the item for the current map, and view the Item Content”. At last, I thought I had my answer. But the link provided is for SaaS clients, which we are not (on prem only). After more digging I found that I could access this functionality by downloading WebOffice, which looks as though we would have to contact support to request a license. After all of that I would be able to find the table's id in the map, just to use in this one activity. But I remembered ArcGIS Online Assistant and knew I could connect to our on prem Portal and view the maps JSON and find the Item Id there….all for an Item Id.
So I will leave this here for others who find themselves in the same situation.1. Log into ArcGIS Online Assistant
2. Choose "View Items JSON" and select the map
3. Find the Item ID for the table
I hope this is addressed in future versions.
0 -
Randy Casey Thanks for your feedback on this. Sorry it's taken me a while to return to this thread. I agree that the debug process in Mobile is much more challenging than in the browser. There are some technical limitations there that we're trying to work with. When dealing with a language like .NET, it's a bit more tricky to produce interactive serialized views of objects and make them all navigable after the fact.
In fact, I think in browsers if you log the same object several times then go back and expand the first one to inspect it you actually get the final state. They re-use the same object there.
If we're not careful we could be using up a lot of memory creating copies of all the objects being logged along the way.
I'll follow up with the Mobile team to see what we might be able to do to improve the debugging experience. I also know we've done some work lately on improving performance so hopefully that's getting better too.
0 -
Just a quick note to say that even though Item Manager is a SaaS-only delivered product, it can work with your on-premises ArcGIS Enterprise (even one in an intranet). You just need to register a subdomain so that it knows how to sign you into your portal.
0 -
Ken Lyon Thank you for your response. Since my last post, I have had much experience with working with VSM. The pain points I mentioned before are still present, but I have learned enough to create my own work-a-rounds, such as pseudo breakpoint workflow that I created which will stop the workflow at specific points I want and even allow me to read in objects that might have fallen off the log, since logs now drop older debug lines (which is new pain point introduced shortly after my last post). I do appreciate the complexity of porting over JavaScript to .NET, so I am empathetic to the struggle, but I will say my last project went about 4 months past my deadline due to problems in the Workflow that kept creating barriers and were very hard to pinpoint (hence the catalyst for my breakpoint workflow). I realize this is not going to be fixed overnight, so I will try to be patient as your dev teams try to work this problem.
1
Please sign in to leave a comment.
Comments
12 comments