Making custom domain objects RPT-enabled - Ocean - Schlumberger

Making custom domain objects RPT-enabled 

April 12th, 2011 Carlos Rocha, Flávio Ivan Silva, Schlumberger 

First published in SWITCH: SOFTWARE & IT CHANNEL NEWSLETTERS, 2011 

Reference Project Tool (RPT) is a Petrel* functionality that allows teams to collaborate by sharing 

data between two different projects. For instance, the user might want to use RPT to transfer well 

logs, templates, windows, seismic data and custom domain objects from one project to another. 

This article focuses on how to make custom objects available in the RPT interface through the 

implementation of specific Ocean* APIs. Code samples along with persistence issues are showed in 

order to illustrate the basics of the API. 

1. Introduction to RPT 

Reference Project Tool is a Petrel functionality that allows users to easily compare and copy domain 

objects (both native and customized) between two different projects: the one currently opened 

(Working project) and the other set as the reference (Background project). 

In the case of a custom object XYZ added to a given project, the user may open the Reference 

Project Tool dialog by going to File -> Reference Project Tool, and then defining the file path of 

another (Background) project. If both projects had a copy of a given XYZ object, the user may be 

able to see which of the instances of this object is newer, and possibly copy it from one project to 

another. 

Ocean Developer Best Practices: Ocean for Petrel framework Page 1 of 9 

Submitted by the developer community 

*Mark of Schlumberger. Other company, product, and service names are the properties of their respective owners. Copyright © 2011 

Schlumberger. All rights reserved.

Figure 1: RPT interface and the same XYZ object in both projects 

2. Persistence of a custom domain object 

As RPT involves opening and copying objects between different projects, the persistence of the 

objects in the Working and Background projects is a pre-requisite for having RPT properly 

functioning. 

The persistence of a custom domain object may happen according to two approaches: (a) by 

normal .NET serialization (ISerializable); or (b) by Ocean infra-structure for serialization 

(IIdentifiable and IDataSource). 

In this article, the Ocean approach will be used. Such strategy involves first giving to any custom 

domain object instance an ID, or a DROID (Durable Runtime Object Identifier). This is 

accomplished by the implementation of the Slb.Ocean.Core.IIdentifiable interface. 

public class XYZObject : IIdentifiable 

{ 

private Droid objectDroid = Droid.Empty; 

public XYZObject() 

{ 

CustomDataSource ds = CustomDataSource.Get(DataManager.DataSourceManager); 

this.objectDroid = ds.Add(this); 





} 

public Droid Droid 

{ 

get { return this.objectDroid; } 

} 

} 

With the implementation above, each XYZObject instance will have a unique identifier (Droid). This 

Droid is the key for saving this XYZObject in its CustomDataSource, which will be kept together 

with other data sources in the Petrel project DataManager. 

Figure 2: Schematic of the Ocean approach to serialization 

3. Implementing a custom data source 

To implement the custom data source, three steps must be followed. 

1) 1. Implementation of a data source factory, by extending DataSourceFactory, like in the example 

below: 

class CustomDSFactory : DataSourceFactory 

{ 

(…) 

public override IDataSource GetDataSource() 





{ 

return new CustomDataSource(this.fileName, this.dataSourceID); 

} 

} 

2. Registering the factory in the Petrel project DataManager, on the Petrel Module initialization: 

public void Initialize() 

{ 

CustomDSFactory dsf = new CustomDSFactory("CustomXYZ.dat", “My_DS_ID"); 

PetrelSystem.AddDataSourceFactory(dsf); 

} 

Notice the CustomXYZ.dat file will contain the serialized custom objects: 

Figure 3: File containing the DataSource serialized 

3. Finally, the implementation of the custom data source that deals with 

serialization/deserialization and keeps a Hashtable to store the custom object and its Droid Id: 

public class CustomDataSource : IDataSource 

{ 

public CustomDataSource(string fileName, string dataSourceIdentifier) 

{ 

this.customObjectsDictionary = new Hashtable(); 

(…) 

} 

// Adds an object and its droid to the dictionary 

public Droid Add(IIdentifiable customObject) 

{ 

Droid objectDroid = customObject.Droid; 

if (objectDroid.Equals(Droid.Empty)) 

objectDroid = new Droid(Id, Guid.NewGuid().ToString()); 

this.customObjectsDictionary.Add(objectDroid, customObject); 

return objectDroid; 





} 

// Called by the framework when user opens a Petrel project file 

public void Open() 

{ 

(…) 

using (FileStream file = fileInfo.OpenRead()) 

{ 

BinaryFormatter bf = new BinaryFormatter(); 

this.customObjectsDictionary = bf.Deserialize(file) as Hashtable; 

} 

} 

// Called by the framework when user saves a Petrel project file 

public void Save() 

{ 

(…) 

using (FileStream fileStream = fileInfo.OpenWrite()) 

{ 

BinaryFormatter bf = new BinaryFormatter(); 

bf.Serialize(fileStream, this.customObjectsDictionary); 

} 

} 

} 

The Add() function is used to store IIdentifiable objects and its droid in a hashtable. Open() 

deserializes a binary file in order to fill the hashtable and Save() serializes the hashtable into a file 

stream. 

4. Important notes about serialization 

There are two very important remarks to be done about serialization: 

1) 1. If a custom domain object contains references to other Petrel domain objects, it must serialize 

only the Droid’s of such references and not the objects themselves. Observe the example below: 

[NonSerialized] 

private SeismicCube internalSeismicCube; 

private Droid seismicCubeDroid; 

2) 2. Before calling the serialization (CustomDataSource.Save() method), any events on the objects to 

be serialized must be turned off. 

obj.Changed -= this .changedEventHandler; 

Such events must probably be linked again after the serialization has finished executing. 





5. Implementing RPT 

To be RPT-enabled, a custom object must implement ISyncable methods: Overwrite, Copy, 

CompareTo and CreateSnapshot. Henceforth, the term “target” is used to mean the project where 

the custom object will be placed and the term “source” to mean which project it came from. 

5.1. Overwrite 

The Overwrite method is called when Petrel identifies that the object to be transferred is already 

present in the target side, which means that a overwriting is going to occur. 

Figure 4: The XYZ object at right will be overwritten by the one at left 

The code below shows an example of how the Overwrite method looks like when the XYZ custom 

object is going to be overwritten. 

public void Overwrite(object source, OverwriteContext context) 

{ 

XYZObject xyzSource = source as XYZObject; 

this.x = xyzSource.X; // Copying the object fields from source to target (this) 





this.y = xyzSource.Y; 

this.lastModified = xyzSource.LastModified; // Datetime indicates changes 

this.droid = xyzSource.Droid; // When overwriting, droid is the same 

} 

5.2. Copy 

The Copy function is called either when XYZ is not present in the target side or when user selects 

“Copy mode” checkbox before transferring. In “Copy mode”, the custom object does not maintain 

its identity as a new one will be created in the target side. 

Figure 5: XYZ object being copied from left to right 

The code below shows the Copy function and its CopyContext parameter. A new XYZ object will be 

constructed depending on whether it has to keep its identity (KeepIdentity equals false when in 

“Copy mode”) and will be added to the target data source. 

public object Copy(CopyContext ct) 

{ 

CustomDataSource source = CustomDataSource.Get(DataManager.DataSourceManager); 

CustomDataSource target = ct.TargetDataManager.GetSource(source.Id) 

as CustomDataSource; 





Creating and returning a new XYZObject 

return new XYZObject(this, target, ct.KeepIdentity); 

} 

5.3. CompareTo 

This function dictates the icon types of the RPT interface and it is called by the framework 

whenever comparisons are needed. There are two types of comparisons: (a) by identity, where the 

Droids of the objects are compared to check whether they are identical; (b) by version, where time 

stamp is compared. When the droids of both objects are equal, the comparison is by time stamp. 

This is shown in the code below. 

public ComparisonResult CompareTo(object other, CompareContext context) 

{ 

if (other is XYZObject) 

{ 

XYZObject xyz = other as XYZObject; 

switch (context.Comparison) 

{ 

case WellKnownComparisons.ByIdentity: 

// Comparing the droids 

return this.Droid.Equals(xyz.Droid) ? 

ComparisonResult.Equal : ComparisonResult.NotEqual; 

case WellKnownComparisons. ByVersion: 

// Comparing the timestamps 

if (this.LastModified < xyz.LastModified) 

return ComparisonResult.LessAndNotEqual; 

else if (this.LastModified > xyz.LastModified) 

return ComparisonResult.GreaterAndNotEqual; 

return ComparisonResult.Equal; 

default: 

return ComparisonResult.NotSupported; 

} 

} 

return ComparisonResult.NotEqual; 

} 

5.4. CreateSnapshot 

This function is called to create a new custom object that will be passed to the Copy function, as 

part of CopyContext parameter. For the sake of this example, this function can simply return null 

as the Copy function already took care of the creation of the XYZ object. 





public object CreateSnapshot() 

{ 

return null; 

} 

6. Conclusion 

In this article, we analyzed the basics of the Ocean API that deals with persistence and RPT. That 

involved going through the implementation of interfaces like IIdentifiable and ISyncable and we 

also mentioned important remarks to take into account when making your custom domain objects 

RPT-enabled.

Making custom domain objects RPT-enabled - Ocean - Schlumberger

Create successful ePaper yourself

Delete template?

Save as template?