XECMv21.2 DateBiz Prop -- Undocument Requirement/Bug

Clarke · 2021-08-30T20:05:19+00:00

There was an error rendering this rich post.

Hello xECM Integration Community,

I post rarely here but wanted to share a bit of critical information about the Extended ECM ECMLink Web Service and Business Properties with this community.

There is an undocumented requirement that the Windows Server clock of the Content Server must be set to UTC. Failing to set this clock to UTC will result in Date Business Properties not being parsed correctly and the value stored to the mapped Category Attribute will be set to the previous day.

Example:

In the thread, you can see the String Date value for the Business Property entering the the XECM OScript. Below is a cut down sample from the thread:

INFO _ApiName = 'InvokeService'

INFO Arguments =

...

Name''=''DateBizProp'',''Values''={''1980-10-10''}>

As you can see above, value is passed into the thread from the ECMLink WSDL

Sadly, and undocumented anywhere, if the Content Server Windows Clock is not set set to UTC 1980-10-10 will be parsed incorrectly to 1980-10-09 by the OScript.

In other words, to use Date Business Properties you must run Content Server in UTC. It is only possible to get the Date Business Property set to the correct value by running the Content Server in UTC.

However running the Content Server in UTC introduces new problems because the Content Server Audit log will then be mixed between Local Time and UTC, so events can appear in the wrong Order.

Because this information is not stated in any Official Documentation, I felt the need to share this with the Community here. OpenText should Document this limitation of Extended ECM in Release Notes, or better yet fully Support running Content Server in whatever timezone the Client chooses.

Regards,

-MC

Find more posts tagged with

Comments

mbarben

Hi Mike,

Just to confirm - if you add a document/folder with that category filled in, does the date/time get stored as UTC or your local time zone?

If so, what makes a connected workspace so special that it does not behave like any other object in the system? (I am assuming you are thinking the same thing Mike).

Regards,

Matthew

Appu Nair

I am with @mbarben on this, I will send a recorded video to OT support on how the behavior is based on some simple tests involving the GUI.

What does the User see in the GUI when they enter category data with or without the TZ offset settings in Classic and SmartUI and what does the LLATTRDATA for that row record? a corresponding one using the GUI to create a workspace.
Do they look wildly different if done through SOAP UI simulating the WSDL creation?
Do they look wildly different if done through POSTman simulating the REST version of that?
Do they look wildly different if done through a WR Tag thereby ruling out Oscript or the higher API's(in my mind WSDL or REST)
Does OT have a disclaimer saying XECM product has to run in a UTC windows server? I know not and I thought the DB was the say in how it was done. Certainly not wouldn't it run in Linux distributions?
After the previous date was being set what would it look if one were to update it to the current time what the user wants does it stick?

Since OT works in siloed development teams sometimes getting the attention of the right team is a challenge, if in doubt involve the Product owner and ask OT support for the Customer Escalation manager.

Clarke

Hello Mathew,

These are "real" Business Workspaces (not Connected Workspaces) meaning that they are created by the ECMLink WebService when invoked from the Leading System/LOB App.

Each Workspace is linked back to a LOB object in the Leading System.

You can tell the different between a Connected Workspace and "real" Business Workspace by seeing all the Reference Information set on the General Tab.

Here is the flow:

Leading Application called ECMLink wsdl createOrUpdateWorkspaces providing all the BizProps (including the a Date BizProp in my scenario). All the BizProps are passed to the wsdl as Strings.

The ECMLink web service then passes all this information to Content Server.

All the BizProps are passed into the XECM module as a giant Assoc. You can see the correct value in the input args in the thread log.

Inside the XECM OSpace code there loads of pathways.

Is it a BWS Update or a Create. If it is a Create, is Bulk Mode enabled in the XECM config?

Regardless of the pathway for Date BizProps there is a Parse from String to Date.

This issue only comes up if you a Date Category Attribute mapped to a BizProp.

The problem I am reporting here, and have tried to massively Escalate a OpenText, is for the Date BizProp do not get set correctly unless Content Server Windows Clock is set to UTC.

Failing to set the clock to UTC results in a bad parse and the wrong Date is stored.

So if you send a Date of Birth BizProp via ECMLink createOrUpdateWorkspace with a value of says 2001-01-01 and do not have OTCS running on UTC, the value stored to the mapped Date Attribute will be 2000-12-31

Running the Content Server in UTC, and having all the BWS Create and Modify times in UTC, is unacceptable to my Client. They want all times to be in their Local TimeZone. They take this position because they want all Audit Information to be in perfect chronological order. With the above, undocumented requirement, all BWS are in UTC. All User Operations are in Local Time Zone.

Since the Audit log does not also store the TimeZone, it is very confusing. How can I tell my Client they are wrong. My job as a Consultant is to Deliver Success and "bend" the software to their needs.

I have tried to engage OpenText on this issue on Ticket # 4832650: CSv21.2 Biz Properties and Systems Times Messed Up opened on Created : 5/17/2021 11:16AM

So it has been 4 months, still no fix. My Client is planning to Go-Live in September but a lack of a resolution on our TimeZone issue has put the whole Project in jeopardy.

I have Emailed the XECM Project Managers and all my Contacts in Support.

I need OpenText to solve this problem for me.

Failing that, I (dreadfully) putting back on my OScript hat to try and create a Partner Patch to remove the UTC requirement. I am not an OScript Developer, this not a strength of mine. My practice stays out of OScript and focuses on WebReports and ActiveView for Customization.

While OScript is great, it is too much for me.

Regards,

-MC

Appu Nair

@Clarke

You said that you do not do much Oscript but should you in case want to tackle this on your own here are a couple of screencaps to trace that code. I will put that in our slack area.

Clarke

Thanks for comments.

I've decided to not even try and fix it. I don't do OScript and I cannot start fixing OT bugs for OT. That destroys the Support Model.

Hopefully OT will engage and help resolve this matter for my Client.

I don't do movies but attached are some screens to further illustrate what I am talking about.

The final pic, 03 Result.png is correct when OTCS Windows Server clock is set to UTC. It is wrong (as illustrated) when OTCS runs in the Local TimeZone.

Regards,

-MC

01 ECMLink createOrUpdateWorkspaces.png

02 Incoming ECMLink Request in thread.png

03 Result in Category.png

Clarke

I'm not a big fan of movies, so here are some pics capturing the issue.

The final pic, 03 Result in Category.png, is correct when the OTCS Windows Server runs on UTC, but incorrect when it runs in the Client's Local Time Zone.

Regards,

-MC

01 ECMLink createOrUpdateWorkspaces.png

02 Incoming ECMLink Request in thread.png

03 Result in Category.png

Appu Nair

@Clarke

Who is responsible for producing the PayLoad? is it OT ? is it ABAP, SalesForce, Success Factors, or any OT Vended XECM or is it a custom XECM APP you developed and using the ECMLINK soap service?? All developers have access to the SOAP CreateOrUpdateWorkspaces and I do see some flexibility in sending a locale in date attributes so to rule a problem in OT software I would stay away from your LOB and write a full soap message in SOAPUI and try sending different date things in your server set for MNT time and see if there is any way that by successfully altering the BizProps date wrapped with some creative locale info it can be set right. Then if it is an OT Vended app then you can definitely say a bug is observed

I have posted a sample soapui payload as well and some ways I sent dates across.

again this goes back to what @mbarben and I asked what would happen in the case a Folder with that category is created when the server is set to MNT would it go wrong? you don't seem to answer that but seems to concentrate only on the Integration code part :)

Clarke

It's a Custom Solution. In the example I posted, I send the request from my example C# project. For the actual integration the Leading Application is Java based. I have been working with this Client for ~18 months to Develop this Solution.

I have created extensive xECM examples as I worked with the Leading App Development explaining how to Integrate the two systems. SOAPUI, C# Client, Java Client, the result is the same.

One solution is to simply add a day to the Date. So send 2001-01-02 to get 2001-01-01. But this is rejected. These are extremely secure records so "fudging" things is not acceptable.

Also there is concern about what happens depending on the time of day the request is sent.

If a User Creates or Edits a Folder or Uploads or Edits a Document all times are in the Local Time. The only times in UTC are the BWS/ECMLink operations.

Ultimately the Client already has a repository for these Documents. They are (trying) to adopt XECM as part for simplified Records Management and eDiscovery purpose and I am trying to Successfully onboard this BU into OpenText.

As part of the Project we upgraded from CSv16.2.11 to CSv21.2 because Support promised us it would be easier to get fixes for identified issues if we were on the latest and greatest.

Hopefully a patch for this time issue, while minor, will be forthcoming because it is important to the Client.

It is only important to me because it is important to the Client. My ECM practice is very small and do everything in my power to try bring success to my Clients.

Regards,

-MC

Appu Nair

Thanks....

One solution is to simply add a day to the Date. So send 2001-01-02 to get 2001-01-01. But this is rejected. These are extremely secure records so "fudging" things is not acceptable.

Have you tried sending a Date that is with a "locale" see an example

<urn1:Properties>
      <urn1:Name>statusdate</urn1:Name>
      <urn1:Values><![CDATA[1998-09-03T12:55:00Z]]></urn1:Values>
    </urn1:Properties>

or are you past the wanting to "try" stage?

Clarke

No I have not! But I will in a moment. We tried other formats for the Date but now what the one you have provided. Let me try and I will report the results.

Please standby. Wow, great to some real help!!!!

Regards,

-MC

Clarke

I tried sending a sending the Date BizProp in using different iterations of what you suggested.

Either they were one day back or ignored by XECM (and the Date didn't change). The closest I got was using 1998-09-03T07:00:00Z. However when I look at the row in LLAttrData the value is 1998-09-03 02:00:00.000.

The value needs to be 1998-09-03 00:00:00.000

Ultimately these are Dates, not DateTimes. There is no Time Component.

It seems that the OScript code needs understand the difference and stop jacking the Time around and messing up the result.

is there something besides Z I can send?

I'm building the prop in C# like this:

var dobProperty = new BusinessProperty();

dobProperty.Name = "BirthDate";

dobProperty.Values = new string[] { "1998-09-03T07:00:00Z" };

Regards,

-MC

Appu Nair

You might read up on this site http://tutorials.jenkov.com/java-internationalization/simpledateformat.html#set-time-zone-of-simpledateformat

Since C# adopts almost everything Java does there might be semantic explanations on what that Z is specifying I wrote that code about 9 months so I don’t remember what it means:)

I just read that and Z signifies UTC. ( GMT)