Highlighted
psciascia Honored Contributor.
Honored Contributor.
4116 views

What is the best way to get a process item's tip revision in the current view?

Jump to solution

I use cr.getFromHistory(DateTime.now()) to get the latest revision.

I notice that sometimes I get a cr that's in a different view.

Looking at the javadoc, I see:

public ViewMember getFromHistory(DateTime date)

Returns the most recent version of this resource as of the specified date. Returns null if a version is not found that existed as of the given date. Note that this query is not view specific. So it is possible to retrieve a newer revision than the specified one, depending upon the value of the DateTime parameter
 
knowing that now, which is the best way to get the tip revision of the cr in it's own view?
 
Thanks
Tags (1)
0 Likes
Reply
3 Solutions

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
ChangeRequest cr = cr.getView().findViewMember(cr.getServer().getType.CHANGE_REQUEST, cr.getVMID());
cr is the tip revision...
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
protected void compareViewConfigurations(View v) {
ViewConfigurationDiffer viewDiff = new ViewConfigurationDiffer(v);
...
ViewConfiguration oldConfig = ViewConfiguration.createFrom(m_dtStartTime);
ViewConfiguration newconfig = ViewConfiguration.createTip();
viewDiff.compare(oldConfig, newconfig);
...
}


are you closing the 2 view objects when done, and before exiting the method? (below)
oldConfig.close();
newConfig.close();

leaving rolled back view's open is both a drain on memory as well as could have unintended side effects, possibly similar to what you are experiencing.
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
yes, there does appear to be a mismatch between your expectations and the way the differ algorithm is implemented.

from what i can tell examining the code, the ideal use of a ViewConfigurationDiffer is a single pass through
for a compare() across 2 configurations. Internally, the differ creates a rolled back view based on the specified configuration, refreshes it, changes the base configuration, then refreshes it, and fires the events associated with the computed differences. If it's reused across multiple compares, it's setting and resetting the underlying rolled back view to different points in time, which is very likely to have indeterminate results.

so effectively...
View v ...
ViewConfigurationDiffer vcd = new ViewConfigurationDiffer(v);
vcd.compare(config1, config2);
vcd.close();

so each time you run the differ, you'd set up the listeners, run the compare, then close the view.
here's a small piece of code that demonstrates the idea...


public class CRxxx implements FolderUpdateListener,
ItemUpdateListener, ViewMemberUpdateListener {

public void testViewMembers(View vw, File f1, File f2) throws IOException, InterruptedException {

ViewConfiguration vc1 = ViewConfiguration.createFrom(vw.getServer()
.getCurrentTime());
// create some objects
Thread.sleep(1000);
ViewConfiguration vc2 = ViewConfiguration.createFrom(vw.getServer()
.getCurrentTime());

ViewConfigurationDiffer vcd = new ViewConfigurationDiffer(vw);
vcd.setAllPropertiesRequired(vw.getServer().getTypes().FILE);
vcd.setAllPropertiesRequired(vw.getServer().getTypes().FLDER);
vcd.addViewMemberUpdateListener(this,
vw.getServer().getTypes().FILE);
vcd.addViewMemberUpdateListener(this, vw.getServer().getTypes().FOLDER);
vcd.compare(vc1, vc2);
vcd.close();
}

public void folderAdded(FolderUpdateEvent e) {
System.out.println("folder added " + e.toString());
}
public void folderMoved(FolderUpdateEvent e) {
System.out.println("folder moved " + e.toString());
}
public void folderChanged(FolderUpdateEvent e) {
System.out.println("folder changed " + e.toString());
}
public void folderRemoved(FolderUpdateEvent e) {
System.out.println("folder removed " + e.toString());
}
public void itemAdded(ItemUpdateEvent e) {
System.out.println("item added " + e.toString());
}
public void itemMoved(ItemUpdateEvent e) {
System.out.println("item moved " + e.toString());
}
public void itemChanged(ItemUpdateEvent e) {
System.out.println("item changed " + e.toString());
}
public void itemRemoved(ItemUpdateEvent e) {
System.out.println("item removed " + e.toString());
}
public void added(ViewMemberUpdateEvent e) {
System.out.println("vm added " + e.toString());
}
public void changed(ViewMemberUpdateEvent e) {
System.out.println("vm changed " + e.toString());
}
public void removed(ViewMemberUpdateEvent e) {
System.out.println("vm removed " + e.toString());
}
}


There is also another class in the SDK you may find interesting.
It's the ViewPollingAgent.
It does something similar, but you control the refreshes.
(You'll find example usage of the ViewPollingAgent in the test suite)
It feels better suited to the problem you're trying to solve..

take care
anil
0 Likes
Reply
19 Replies
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
hmm,

so, you have a CR in hand, but don;t know which view it actually belongs to 'now'
it could have been shared or moved from some other view.
so you could effectivly end up with multiple CRs that are shares of each other.

so i guess a corollary to your question is which share do you care about?
which view do you care about?

to answer these questions, you'd have to examine and walk the share tree
cr.getAllShares()
find each share in each view, then find the tip revision of that share in that view... effectively...
view.findViewMember(myServer.getTypes().CHANGE_REQUEST, share.getVMID()).getRevision()
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
The view I care about is the view of the CR I am processing.
This is why cr = (ChangeRequest)(cr.getFromHistory(DateTime.now())) did not work because it may return a different cr.
Since I care about only working with the lastest revision of the CR I currently hold, instead of walking the share tree, could I do something like that.

int latestRev = cr.getView().findViewMember(cr.getServer().getType.CHANGE_REQUEST, cr.getVMID()).getRevisionNumber();
ChangeRequest latestCr = cr.getFromHistory(latestRev);
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
ChangeRequest cr = cr.getView().findViewMember(cr.getServer().getType.CHANGE_REQUEST, cr.getVMID());
cr is the tip revision...
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
Ok thanks, so the last line is redundant. Super thanks.
To give you a little context, I use this in my "PastEventsProcessor" is run when I launch my watcher application. We discussed this before, and I use ViewConfigurationDiffer to fire all events that occurred since the watcher was last closed.
When an event is launched and I validate the fields of process items, I want to know, even though ItemChanged events are processed, that I validate the fields on the tip revision of the items in case the fields were modified since "past"the event occurred.
I do encounter an issue with that, and I don't know if I've ever mentioned this, but when I run the compare, I get events that occured months ago. I had to add and extra validation with the newItem's modifiedTime - to make sure it actually item's modification occured in the span, which is usually less than 24 hours.

Is this something you can explain?
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
Hi Patrick,
I am sorry. I do not have enough data to provide an explanation.
If you open a support case with MicroFocus and provide a small test that reproduced the problem, I shall certainly investigate.
Take care
Anil
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
OK thanks. I've added logs to my watcher application so that it can illustrate it better. Since then., I have not run into the issue. Of course!
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
Ok, it happened today. I have my logs from which I can attach an excerpt. I imagine they can tell me what else is needed.

For now, for a little preview, here is a bit from the code and the log.
It's pretty much always the same thing. It starts with an ItemUpdateEvent event trapped by Item added for something that occured way before the 'old config.
You see from the logs that I run a compare of the view between Dec 6th @ 6:11PM and December 7@ 9:19AM. The an event is trapped by ItemAdded from November 29th.

The code that compares looks like this:

protected void compareViewConfigurations(View v) {
ViewConfigurationDiffer viewDiff = new ViewConfigurationDiffer(v);
...
ViewConfiguration oldConfig = ViewConfiguration.createFrom(m_dtStartTime);
ViewConfiguration newconfig = ViewConfiguration.createTip();
viewDiff.compare(oldConfig, newconfig);
...
}

The first lined of ItemAdded lok like this, to demonstrate how I get the information in the log

public void itemAdded(ItemUpdateEvent e) {
String sOut = String.format("Item added at %s. Event: %s\n",
e.getNewItem().getModifiedTime().toLocalString(),e.toString());
appendToLogFile(sOut);
...
}


And here's the bit of the log.


07/12/17 9:19:47 EST AM Creating old view config at this time 06/12/17 6:11:43 EST PM

07/12/17 9:19:47 EST AM Getting the current (tip) view config for comparison (Current Time: 07/12/17 9:19:47 EST AM).

07/12/17 9:19:50 EST AM Item added at 29/11/16 10:32:24 EST AM. Event: ItemUpdateEvent(Change Request, "10,274")

07/12/17 9:19:50 EST AM Item changed at 29/11/16 10:32:44 EST AM. Event: ItemUpdateEvent(Change Request, "10,274")

07/12/17 9:19:51 EST AM Ignored modification in past events on CR10274 by Marlene on 29/11/16 10:32:44 EST AM.
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
protected void compareViewConfigurations(View v) {
ViewConfigurationDiffer viewDiff = new ViewConfigurationDiffer(v);
...
ViewConfiguration oldConfig = ViewConfiguration.createFrom(m_dtStartTime);
ViewConfiguration newconfig = ViewConfiguration.createTip();
viewDiff.compare(oldConfig, newconfig);
...
}


are you closing the 2 view objects when done, and before exiting the method? (below)
oldConfig.close();
newConfig.close();

leaving rolled back view's open is both a drain on memory as well as could have unintended side effects, possibly similar to what you are experiencing.
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
In fact I wasn't. The lines are now in, thanks.
I'll let you know if the results are positive.
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
Ok I lied, the lines were about to be in.
I see no close() method in Class ViewConfiguration.
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
sorry... you are right...
i meant,
viewDiff.close()

which closes the configurations which are passed in.
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
Now perhaps this is a design flaw from my side, but closing the viewDiff closed my realtime listeners. There may be confusion in the listeners.

My main watcher does this:
for each monitored view
1) setup the listeners
2) run the PastEventProcessor on that view *on the first run of the loop*, using the current view to setup the viewDiff.

pseudo-code
for (View v : vv){
run(v); //create and map ItemListeners to the view
if(firstRun){
RunPastEventProcessor(v); //compare the current state to the view state the last time the app was closed and cat ch events
}
}

Is it possible that when I close the viewDifff, it disables the listeners I seton my view in the main program?
My Main program uses ItemListeners, but the PastEventProcessor uses ItemUpdateListener.
I've taken out the close() while I figure out what is going on.
0 Likes
Reply
Micro Focus Expert
Micro Focus Expert

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
yes, there does appear to be a mismatch between your expectations and the way the differ algorithm is implemented.

from what i can tell examining the code, the ideal use of a ViewConfigurationDiffer is a single pass through
for a compare() across 2 configurations. Internally, the differ creates a rolled back view based on the specified configuration, refreshes it, changes the base configuration, then refreshes it, and fires the events associated with the computed differences. If it's reused across multiple compares, it's setting and resetting the underlying rolled back view to different points in time, which is very likely to have indeterminate results.

so effectively...
View v ...
ViewConfigurationDiffer vcd = new ViewConfigurationDiffer(v);
vcd.compare(config1, config2);
vcd.close();

so each time you run the differ, you'd set up the listeners, run the compare, then close the view.
here's a small piece of code that demonstrates the idea...


public class CRxxx implements FolderUpdateListener,
ItemUpdateListener, ViewMemberUpdateListener {

public void testViewMembers(View vw, File f1, File f2) throws IOException, InterruptedException {

ViewConfiguration vc1 = ViewConfiguration.createFrom(vw.getServer()
.getCurrentTime());
// create some objects
Thread.sleep(1000);
ViewConfiguration vc2 = ViewConfiguration.createFrom(vw.getServer()
.getCurrentTime());

ViewConfigurationDiffer vcd = new ViewConfigurationDiffer(vw);
vcd.setAllPropertiesRequired(vw.getServer().getTypes().FILE);
vcd.setAllPropertiesRequired(vw.getServer().getTypes().FLDER);
vcd.addViewMemberUpdateListener(this,
vw.getServer().getTypes().FILE);
vcd.addViewMemberUpdateListener(this, vw.getServer().getTypes().FOLDER);
vcd.compare(vc1, vc2);
vcd.close();
}

public void folderAdded(FolderUpdateEvent e) {
System.out.println("folder added " + e.toString());
}
public void folderMoved(FolderUpdateEvent e) {
System.out.println("folder moved " + e.toString());
}
public void folderChanged(FolderUpdateEvent e) {
System.out.println("folder changed " + e.toString());
}
public void folderRemoved(FolderUpdateEvent e) {
System.out.println("folder removed " + e.toString());
}
public void itemAdded(ItemUpdateEvent e) {
System.out.println("item added " + e.toString());
}
public void itemMoved(ItemUpdateEvent e) {
System.out.println("item moved " + e.toString());
}
public void itemChanged(ItemUpdateEvent e) {
System.out.println("item changed " + e.toString());
}
public void itemRemoved(ItemUpdateEvent e) {
System.out.println("item removed " + e.toString());
}
public void added(ViewMemberUpdateEvent e) {
System.out.println("vm added " + e.toString());
}
public void changed(ViewMemberUpdateEvent e) {
System.out.println("vm changed " + e.toString());
}
public void removed(ViewMemberUpdateEvent e) {
System.out.println("vm removed " + e.toString());
}
}


There is also another class in the SDK you may find interesting.
It's the ViewPollingAgent.
It does something similar, but you control the refreshes.
(You'll find example usage of the ViewPollingAgent in the test suite)
It feels better suited to the problem you're trying to solve..

take care
anil
0 Likes
Reply
psciascia Honored Contributor.
Honored Contributor.

RE: What is the best way to get a process item's tip revision in the current view?

Jump to solution
Before I left yesterday, I read that ViewConfigurationDiffer.close actually closes the view.
So I thought, that simply inverting my calls would do the trick - and it does.

So, from my previous post, I make the following change:
for (View v : vv){
if(firstRun){
//compare the current state to the view state the last time the app was closed and catch events
RunPastEventProcessor(v);
//create and map ItemListeners to the view
run(v);
}
}
That way, I create the real-time listeners AFTER I close the view via the PastEventProcessor.

So far it seems to hold, and I did not get any events firing that occurred a month ago.
I will certainly look at the ViewPollingAgent. I like having different flavors of solutions.
Thanks again Anil,
--pat
0 Likes
Reply
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.