There are many workarounds a developer must endure when working with the intricacies of Esri and ArcFM™.
One such workaround encapsulates posting a session via ArcMap and firing a customized subtask.
In a technical sense, posting a session will move the version of the database back to Default so iterating through an ITable might cause a few unwanted headaches.
Like many facets of programming and life, there are many ways to accomplish the same result. This article is a biased perspective on how to work around posting a session that loses all your changes utilizing static classes and refiring a subtask.
Scenario
So let’s create a simple fictitious scenario that will encapsulate our need to utilize a static class and refire of a subtask.
- Create a customized application that will edit or create new users in the database.
- While editing a session within ArcMap, you launch a customized application in ArcMap that edits or updates users.
- These user changes will be saved in the ITable for users. Create a subtask that will grab the user changes in the User ITable and send an email called “Get Users”.
- Have the subtask (Get Users) fire after posting the session and you’ll notice that none of your users will get emailed, because posting a session will place the pointer back to default or the unversioned database.
Solution
Now let’s look at a solution for the dilemma described prior. Basically, launch the subtask prior to the Post Session subtask and after the Post Session subtask.
The first launch of “Get Users” will look to see if a list of static classes that stores properties for the user is null or not. If the static class is null, then the subtask of “Get Users” will store all the changed users in the static User class.
If the static class is not null, then the subtask of “Get Users” will iterate through the user class and send each user an email.
Process Framework Administration Tool Setup
1. Have the “Get Users” subtask fire before the Post Session to grab all the updated users in the ITable.
2. Launch the Post Session subtask after “Get Users”.
3. Launch “Get Users” again
Static Class Implementation
Static classes allow the software engineer to store and reuse information without expensive hits to the database or other data storages.
1. Static class to store user information
/// <summary>
/// User Class
/// </summary>
public class UserClass
{
public string UserId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
}
2. Service Factory or Class that implements the static UserClass. The REALLY important aspect is the last method of ResetValues() because it will null out the UserClass.
public sealed class UserContainer
{
private static volatile UserContainer _instance = new UserContainer ();
private static volatile List< UserClass > _getUserClasses;
private static readonly object SyncRoot = new object();
/// <summary>
/// Static Instance
/// </summary>
public static UserContainer Instance
{
get
{
if (_instance == null)
{
lock (SyncRoot)
{
if (_instance == null)
_instance = new UserContainer ();
}
}
return _instance;
}
}
/// <summary>
/// Get and Set List of UserClass
/// </summary>
public static List< UserClass > UserClasses
{
get
{
return _ getUserClasses;
}
set
{
_ getUserClasses = new List< UserClass >();
_ getUserClasses = value;
}
}
/// <summary>
/// Reset
/// </summary>
public static void ResetValues()
{
_ getUserClasses = null;
}
}
}
Subtask Implementation
The subtask will launch with the Execute method below and verify that the static class is null or hydrated to then verify the logical path of execution.
/// <summary>
/// Execute the subtask
/// </summary>
/// <param name=”pPxNode”>The IMMPxNode</param>
/// <returns>Boolean</returns>
public bool Execute(IMMPxNode pPxNode)
{
if (UserContainer.UserClasses == null)
{
List< UserClass> listUserClass = new List<UserClass>();
//Query the iTable of Users and store in the listUserClass
}
else
{
//Do logic to iterate through each User in listUserClass
//IMPORANT TO RESET VALUES
UserContainer.ResetValues();
}
return true;
}
Conclusion
Though this article was a little bit on the technical side, I feel that sharing the knowledge of how to work around issues that are not completely obvious is a good thing to share.
The above example code was taken from actual code with variables and classes renamed to keep things a little more generic.
I hope you found this article helpful, insightful, and beneficial in your journey as an ArcGIS guru.
Did this article help you overcome an issue you’ve experienced before? Let us know in the comments below.
What do you think?