Skip to main content
November 29, 2016
Solved

DateTime property on Users (via UserExtensions) is not persisting.

  • November 29, 2016
  • 2 replies
  • 2702 views

I am developing on Thingworx 7.0.3

I am having an issue setting DateTime property values on Users from within Java extension package code and having the data persist across Tomcat restarts

Even  in this simple example utilizing a service, the date will not persist over a Tomcat reboot.

However, if I set this value via Composer, it will persist across a Tomcat reboot.

@ThingworxServiceDefinition(name="Test", description ="")

  @ThingworxServiceResult(name="result", description="", baseType="STRING")

  public String Test() throws Exception {

  User usr = EntityTools.GetUser("myUsername");

  usr.setPropertyValue("LastSync", new DatetimePrimitive(DateTime.now()));

  return "finished";

  }

I have also tried setting this via this line, as well, just to see, but with no change.

usr.setPropertyValue(DevicifyConstants.GLOBAL_PROPERTY_LAST_UPDATE_TO_SFDC, new DatetimePrimitive(DateTime.now().getMillis()));

Any ideas?

Best answer by

Sure enough this is a bug, and it is fixed by both 7.2.5 and 7.0.6

2 replies

5-Regular Member
November 30, 2016

Jason Geiger​, Do you see the updated value in composer after running the extension service?

November 30, 2016

Yes. Everything looks great, until a Tomcat restart.

December 1, 2016

More info here, got some time to get back to this. I am beginning to suspect this is a bug so I will put in a case.

I've tried all three constructors for DatetimePrimitive, all accept the date and do not error but tomcat restart looses the data.

The final one, not mentioned above:

DatetimePrimitive dt = new DatetimePrimitive();

dt.setValue(DateTime.now());

usr.setPropertyValue(DevicifyConstants.GLOBAL_PROPERTY_LAST_UPDATE_TO_SFDC, dt);

I have tried initializing DateTime various ways but that is not it either.

I want to test this on 7.2.x to see if it's there but in the meantime I am going to put in a ticket.

Answer
December 1, 2016

Sure enough this is a bug, and it is fixed by both 7.2.5 and 7.0.6