Latest Contributions by Bud

Some thoughts about your deletes idea: I don't think you could use the out-of-box Maximo Spatial integration mechanism (called the ArcGISDataSync cron task) for your deletes idea. Unless you got your consultant to customize the Java, but that sounds pretty terrible. You might need to do something like this in Maximo: Create a custom cron task or escalation -- to run a Python or JavaScript "automation script" on a schedule. The automation script would perform the logic you mentioned above (find GIS assets that have been deleted and mark them as decommissioned in Maximo). Would you connect to GIS using an HTTP call? Or a dblink? The automation script would update the appropriate Maximo records by changing the status to decommissioned. You might find this script interesting: Escalation: Email me if external web service returns any records (JSON) or if service is down. That script is totally different than what you want, but you still might be able to use parts of it. It makes HTTP calls to GIS on a schedule, which seems relevant. I'm not an expert on this stuff. I would definitely recommend bouncing your idea off the folks in the IBM Maximo Community. It's funny, at one point, I'd actually wondered if we'd create a custom Maximo/GIS integration mechanism ourselves, using logic similar to the above -- instead of using the OOB Maximo Spatial mechanism (ArcGISDataSync cron). That mechanism requires a lot of extra Maximo objects to be set up -- which is fiddly, when you have a lot of GIS layers to integrate. And it isn't customizable. I had wondered if we might use the custom mechanism idea mentioned above...since most of the work is already done in that script I mentioned: Escalation: Email me if external web service returns any records (JSON) or if service is down. We probably wouldn't have used it for asset integrations (not necessary in our case), but for integrating WOs from ArcGIS Collector/Field Maps...to Maximo. Either of the two methods would work (custom or ArcGISDataSync -- we tested the later and it worked fine). But it was still interesting to think about...what if we wanted to customize the integration? The automation script would be decent option, I think.   ... View more

Thanks. It turns out, the compatibility issue is with license manager. I can upgrade Pro to version 2.6.8, but anything beyond that would be incompatible with our version of license manager. ... View more

Interesting idea! No, we hadn't looked into that. In our case, we already had a status field in most of our asset feature classes. For example, we have proposed and future assets in there too. So we're used to filtering on status...it comes naturally at this point. ... View more

Yeah, I think they just stay in Maximo forever. We have status fields in our GIS layers. When a GIS asset gets removed due to a road reconstruction, etc, we just change the status to something like removed, decommissioned, abandoned, inactive, etc.  We use that status field to hide the removed GIS assets from various inspection maps, web maps, etc…via a definition query…so that they appear to be deleted. But really they’re just flagged as removed and hidden from sight. In our GIS db views for Maximo, we translate the GIS stratus to a Maximo status, such as Maximo’s decommissioned status. Alternatively, you can create a status “synonym” in Maximo. ... View more

If I've understood correctly (it's possible that I haven't), I think you're suggesting that all rows in all FCs be flagged as needing to be synced to Maximo. We wondered about that too...just sync everything...once a week or once a month. That would be nice and simple. The problem with that is that the Maximo Integration Framework (MIF) is relatively slow. A municipality like @BrianBulla's (or ours) has hundreds of thousands, possibly millions, of asset records. Unfortunately, it would take Maximo several days or even weeks to do a sync like that. So it wouldn't be feasible. The challenge is: How to flag new or updated GIS features -- so that only those changes, aka "the delta" are synced to Maximo. IBM's mechanisms for this sort of thing are naive/incorrect. A lot of organizations try to find alternatives. Companies like ActiveG and GeoNexus have made entire products for it. ... View more

Regarding triggers: No, we didn't investigate them. We have 20-40 GIS layers that we integrate to Maximo. Triggers on 40 layers seemed like it'd be a lot to manage. The db view option seemed simpler for our purposes. And as analysts, we could create and manage the views ourselves, whereas we'd need to get other staff involved with triggers, which would have taken extra time. The db views (and dblink) option I mentioned worked well for us. And like I said, we needed to translate the GIS data for Maximo anyway, so db views worked good for that too. Edit: I forgot to mention that we take the db views and export them to feature classes on a schedule. Reason: static feature classes are faster than views. Regarding deletes: If I remember correctly, once an asset is created (or integrated) in Maximo, Maximo won't allow us to delete it. We can only "decommission" it. So our hands were tied -- we had to come up with a "don't delete GIS assets, only flag them as decommissioned" business rule for our GIS technicians. We'll likely enforce that rule using ArcGIS Pro attribute rules. We've already done it for a couple of FCs. But it sounds like attribute rules aren't an option for you. Is your GIS data versioned? If so, then it isn't possible to allow edits, and at the same time, specifically prevent deletes. At least not through the ArcMap/ArcGIS Pro privilege settings for a given feature class.  With that said, I did come up with a proof-of-concept db trigger that seemed to work with versioned feature classes. But my testing was limited (I didn't end up needing the trigger; we'll probably use attribute rules instead). Prevent deletes in a versioned table at the database level  ... View more

Various other things to keep in mind: Regarding Maximo Spatial's MXCREATIONSTATE / sync mechanism: Bear in mind that when Maximo syncs a record, it will then update the MXCREATIONSTATE field in GIS to "successfully synced" or whatever the actual numeric code is (I can't remember). The problem with that is: I believe the edit will trigger editor tracking, since the edit is done through the ArcGIS REST API. So, if you were using that editor tracking field for other stuff in GIS, then it means that Maximo has compromised your editor tracking info. Your editor tracking will indicate the last time Maximo edited the field, not necessarily the last time a user edited the field. Maximo Spatial's cron task for syncing GIS records to Maximo sometimes fails. There are scenarios where it runs, but nothing happens -- no records are synced. So you don't want to use logic like the following: "If the last Maximo cron run date is less than the GIS last_edited_date, then sync the record". The last cron run date in Maximo will be misleading in that case...records likely failed to sync, and wouldn't be picked up in the next sync. If I remember correctly, GIS's editor tracking fields need to be set to UTC time -- for ArcGIS-specific reasons that I can't remember off hand. However, the time zone in Maximo will likely be different. So comparing date fields between the two systems/time zones can get messy. With that said, we put some thought into the logic at play, and didn't think the time zone thing would end up being a problem for us -- for our weekly asset syncs. ... View more

Ugh, Maximo Spatial. You poor soul. We took a deep dive with our Maximo/GIS integrations a couple of years ago. We abandoned most of the IBM mechanisms, including the MXCREATIONSTATE field thing.  I honestly don’t know where to start. There are so many things I want to warn you about. @jcarlson is on the right track with the last_edited_date thing, as an alternative to MXCREATIONSTATE. We did it by using database views on our feature classes to generate a sync_needed field, in conjunction with a database link to the Maximo database: select ..., case when fc.last_edited_date > maximo_asset.lastsyncdate or maximo_asset.lastsyncdate is null then 1 else 0 end as sync_needed from gis_fc fc left join custom_maximo_owner.asset@gistomax maximo_asset --this is a dblink in the Maximo database that lets GIS select from the Maximo asset table on fc.asset_id = maximo_asset.assetnum --note: lastsyncdate is a custom field we created in the Maximo asset table. It's easy to populate that field with the Maximo system time using the &SYSDATE& default value: https://i.stack.imgur.com/2cNyk.png One additional benefit to using a db view in GIS is that you can translate/format your data before it gets to Maximo. That's potentially easier than trying to do the translation in Maximo's JSON Mapping application.     ... View more

Related ideas: Arcade docs: Equals() function doesn’t consider M-values Arcade function: EqualsMZ()   ... View more

Yeah, although Equals() doesn’t work the way I would have expected…it doesn’t consider changes to M-values: Arcade: Editing M-values not treated as change to geometry So that’s why I went with the text comparison. ... View more

Thanks. Good suggestion about the variables. I tried to clean them up: var geom_text = Text(Geometry($feature)); if (geom_text == Text(Geometry($originalfeature))) { return } function pythagoras(x1, y1, x2, y2) { return sqrt(pow(x2 - x1, 2) + pow(y2 - y1, 2)); } var geom = Dictionary(geom_text); var paths = geom['paths']; var oldX = paths[0][0][0]; var oldY = paths[0][0][1]; var line_length = 0; for (var path_idx in paths) { for (var point_idx in paths[path_idx]) { var newX = paths[path_idx][point_idx][0]; var newY = paths[path_idx][point_idx][1]; if (point_idx != 0) { line_length += pythagoras(oldX, oldY, newX, newY); } paths[path_idx][point_idx][-1] = line_length; oldX = newX; oldY = newY; } } return { "result": { "geometry": Polyline(geom) } };   ... View more

Thanks very much. That helps. As you suggested, I'm looking into updating my version of Pro: What versions of Pro are compatible with 10.7.1 EGDBs? ... View more