nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Aspects on dm_document

leo_the_lion

Hi all

We have an application where we want to use the Aspects.The idea is to apply the aspect on dm_document.

The aspect in our application will require to add /override the behavior only. We are not using any specific attributes.
We are trying to override the behavior of doCheckout , doSave and doDelete depending upon the status of a registered table(ABC_STATUS).

The registered table has a field named as "flag". If the "flag" field is true, doCheckout/doSave or doDelete will throw an exception.

This is how we want the aspects to behave. But the behavior of aspect is not reflecting like if the "flag" field in my registered table is true then

an exception must be thrown and no checkouts should be allowed.

Iam attaching the aspect code [both implementation class as well as Interface class].Iam also attaching the screen shot where I have created

an Aspect on dm_document in Composer.

Please correct me if I am missing something..

package com.xyz.aspect;
import com.documentum.fc.client.DfDocument;
import com.documentum.fc.common.DfException;
import com.documentum.com.DfClientX;
import com.documentum.com.DfClientX;
import com.documentum.com.IDfClientX;
import com.documentum.fc.client.DfDocument;
import com.documentum.fc.client.IDfCollection;
import com.documentum.fc.client.IDfQuery;
import com.documentum.fc.client.IDfSession;
import com.documentum.fc.client.IDfSysObject; //adg add
import com.documentum.fc.common.DfException;
import com.documentum.fc.common.IDfId;
import java.net.InetAddress;
import java.rmi.server.UID;
import com.xyz.aspect.IAspectDocument;
import com.documentum.fc.client.IDfModule;

public class AspectDocument extends DfDocument implements IAspectDocument,IDfModule{

    public AspectDocument()
    {
    }

protected void doSave(boolean saveLock, String versionLabel, Object extendedArgs[])
        throws DfException
    {

     String objID = getObjectId().toString();
     System.out.println("The object id is Aspect called:"+objID);
     System.out.println("doSave called !!!!! Aspect called in save -");

      if(flag(objID))
         {

          throw new DfException ("SAVE operation failed. Cannot since flag is true");
          }

     else
         super.doSave(saveLock, versionLabel, extendedArgs);
    }

protected IDfId doCheckin(boolean fRetainLock, String versionLabels, String oldCompoundArchValue, String oldSpecialAppValue, String    newCompoundArchValue, String newSpecialAppValue, Object extendedArgs[])
        throws DfException
    {

     System.out.println("doCheckin() entered! (Aspect)!!!!!!");
     String objIDChk = getObjectId().toString();


       if(flag(objIDChk))
           {

               throw new DfException ("Save operation failed. Cannot checkin since flag is true");
           }

     else
      return super.doCheckin(fRetainLock, versionLabels, oldCompoundArchValue, oldSpecialAppValue, newCompoundArchValue, newSpecialAppValue,     extendedArgs);

}

    protected IDfId doCheckout(String versionLabel, String compoundArchValue, String specialAppValue,
      Object[] extendedArgs) throws DfException {

     String objIDChk = getObjectId().toString();
     System.out.println("doCheckout entered!!!!! Aspect called -objectID is "+objIDChk);
     System.out.println("doCheckout entered!!!!! Aspect called -");

    if(flag(objIDChk)){
      throw new DfException("Checkout operation failed. Since flag is true");
     }
     else
      return super.doCheckout(versionLabel, compoundArchValue, specialAppValue, extendedArgs);

}

    public void doDestroy(boolean force, Object extendedArgs[]) throws DfException
    {
     String objID = getObjectId().toString();

      if(flag(objID))
     {

         throw new DfException ("Delete operation failed. since flag is true");
     }


     else
         super.doDestroy(force, extendedArgs);
    }

    public boolean flag(String objectID)
    {
     boolean status = false;
     IDfSession qrySession = null;
     //Collection for the result
     IDfCollection recordCol = null;

     try{
     String queryRecord = "select flag from dm_dbo.ABC_STATUS where r_object_id ='" + objectID +"'" ;

     qrySession = getSession();
        IDfClientX clientx = new DfClientX();
        IDfQuery recordQry = clientx.getQuery();
        recordQry.setDQL(queryRecord);
        recordCol = recordQry.execute(qrySession, IDfQuery.DF_READ_QUERY);

        while(recordCol.next())
        {
         String checkFlag = recordCol.getValueAt(0).asString();

          if(checkFlag.equalsIgnoreCase("T")){
           status=true;
          }else{
           status=false;
          }

        }

        if(recordCol != null)
         recordCol.close();

        return status;
     }catch(DfException qryExpection)
     {
      System.out.println("Exception in handling IDfCollection " +qryExpection.getMessage());
      recordCol = null;
      qrySession = null;
      return false;
     }
     }

///Code for Interface Class

package com.xyz.aspect;
import com.documentum.fc.common.DfException ;
public interface IAspectDocument {

}

Thanks in advance.

aspect_screen.bmp

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Button

Accepted answers

msroth

I know it reports "0 rows affected." I did for me too and I don't know why. However, when I created a dm_document the Aspect was attached (for the default aspect). When I ran the update query I also saw that the Aspect was attached. Give it a try and use RepoInt to look at the results.

All comments

aflowers001

How/where are you applying the Aspect to a document instance?

I am guessing that a raw TBO might better suit your purposes.

leo_the_lion

The idea is to call Aspect on all instances of dm_document ( as it has been applied on dm_document instead of a custome type).

Moreover, TBO on dm_document is not recommended by EMC, so we have tried to use this approach for overriding

the doCheckout/doSave and doDelete methods on every instance of document type.

Thanks

aflowers001

Aspects are intended for usage on a generally smaller number of specific document instances and are only active on a per instance basis after being applied to that specific instance. My guess is that as the aspect is not applied when saving the code in it isn't called, but I haven't checked on that. An aspect is not used to override standard functionality rather it is there to add functionality to an object instance, as per the DFC Development guide manual.

A TBO is applied to ALL instances and is the way to do what you are looking to do. Who in EMC had recommended that you not use a TBO? I am aware of a recommendation, if using DFS, to put the business logic there as opposed to a TBO, but at the lowest level a TBO is where to put this kind of logic.

leo_the_lion

Hi Andy

Thanks for the reply.

TBO on dm_document is not recommeded by EMC. So we are not using TBO here. So,we have tried to meet our requirement by implementing Aspects here.

Thanks

aflowers001

Ah, missed the 'dm_document' requirement.

Do you have a common application specific supertype you coukld add the TBO onto? If not then what is your user interface?, as that might be the best place to implement this if there is only one way into the system (althought that isn't the best solution as the next UI/Web Service presents the same problem all over again).

Another option could be, given my limited understanding of your requirement from the code to make the repository read-only, could be to manipulate the ACLs you have when the flag is set/reset? such that objects can be made read-only when required perhaps.

msroth

I agree with Andy's comments on this, a TBO seems like a better implementation choice; however, I also understand your dm_document requirement. Perhaps you need to rethink your object model a little bit so you have a custom supertype where you can apply the TBO? If you want to stick with the Aspect implementation (which seems a little strained in my mind) you will need a way to apply the Aspect to every instance of a dm_document that has already been created, and that will be created. For the dm_documents that already exist, a DQL query will apply your Aspect. For the dm_documents that users will create in the future you will need to find a way to apply your Aspect. You could do it with UI code or just run a job periodically that applies the Aspect.

I am just finishing up a series of blog posts about Aspects and applying them from Webtop if you are interested. http://msroth.wordpress.com/2011/01/27/checksum-aspect-part-0/

msroth

I just had another thought about this.... You can define a "default aspect" to an object type definition. Then, whenever an object of that type is instantiated, it automatically gets the Aspect applied. This would solve your problem with how to attach you Aspect whenever a user creates a document. You can set default aspects using DQL. The question is, can you set one on dm_document. Worth checking out....

leo_the_lion

Hi Scott

Thanks for the reply.

I would like to tell you the steps we have taken in Documentum Composer to attach aspect on dm_document.

1. Jar def for the implementaion class as well Jar def for Interface class for Aspect has been defined in Composer as Artficat.

2. Next,another Artficat for Aspect module has been created .

3. Within the Aspect Module, in General Tab, the referncing jarddef [Implementation jar and interface jar]has been given .

4. In Aspect Type Tab, the target Object is defined as dm_document.

5. Further, the dar file has been created by clicking on build Project.

Now, we suppose that all these steps should have attached our aspect on dm_document and all the documents that would be created after attaching the aspect should reflect the behavior .

So we have stuck here and even cannot conclude that is this the right way to deploy a deault aspect on dm_document

Thanks

aflowers001

Does the aspect methods for, say, doSave() actually get called? i.e. does your logging get written out.

My understanding is that the aspect will only be added to an instance of the object, which means it has already been created.

If the doSave() method, or other are not being called then I think we have an answer that aspects cannot do what you are after, and from my reading about aspects that seems to be what aspects are about, they don't replace existing functionality rather they are there to add extra 'stuff' to an object instance.

lastnitescurry

All those steps should make the aspect available to the dm_document type.

But the aspect must be attached to each individual instance of the dm_document type.

I have not tried "default aspect" thing so do not know if it will be applied when an instance is created.

Suggest you create a DFC script to attach your aspect to a test dm_document instance and then test your functionality.

Personally I have used aspect to immplement recycle bin functionality, in that doCheckin was overridden to prevent changes. For that I had Webtop customised to apply the aspect

msroth

I replied to this earlier via my phone but it never showed up. Here is my previous comment:

Off the top of my head that all sounds right. Now you need to attch the aspect to an instance of a dm_document to see if it works. You can attach the aspect using DQL: update dm_document object append r_aspect_names = <name of aspect> where r_object_id = <object id>. I verified that you can set a default aspect on dm_document thus automatically attaching the aspect to all instances created. You can set the default aspect with DQL also: alter type dm_document add default aspect = <aspect name>. (All DQL entered from memory on my phone so you might want to verify it in the DQL documentation).

leo_the_lion

Hi Scott

Thanks for the reply.

We created a Custom Type testtype2 ,its Supertype is dm_document and tried to attach aspect on that. We did this to test the alter/update command for custom type before going ahead for dm_document. The Aspect name is Aspect01. This Aspect is attcahed to dm_document through Composer.

We excuted

update testtype2 object append r_aspect_name = 'Aspect01'

Output: 0 rows affected.

alter type testtype2 add default aspects 'Aspect01'

Output: 0 rows affected.

msroth

leo_the_lion

Hi Scott

Thanks for the answer. We tried the query and it worked.!!!

We were not able to view the results just becoz the DQL showed up 0 rows afftected. But when new documents were created after running the query

they all had Aspects attached to it and we can see them in Document properties.

But the previous documents which were created earlier [before running the DQL ] didnt have Aspects attcahed to it. Do you have any idea about how to Attach Aspects to those documents.

Regards

msroth

Glad to hear you are having some success. You should be able to update all the other dm_documents to use the Aspect with a similar query. Something like: UPDATE dm_document OBJECT APPEND r_aspect_name = <aspect name>. You will probably want to add a predicate to this query to confine the update to a cabinet or folder or something. I doubt you want to attach your Aspect to ALL dm_documents in the repository. I just posted several DQL queries regarding Aspects in my latest blog entry if you care to read them. http://msroth.wordpress.com/2011/02/28/checksum-aspect-part-5/

leo_the_lion

i Scott

We executed the update query ie. "UPDATE dm_document OBJECT APPEND r_aspect_name = <aspect name>." but were able to apply the

update for a particular cabinet only. So, the aspects are applied /confined only to a particular cabinets that we have to mention explicitly.

But is there any generic query which can update and attach aspects to all the documents created by the user irrespective of being created in any cabinet but before the date on which aspects are deployed .This will bring a sync to existing documents and newly created documents .They all would then have a similar behavior as expectd by Aspect.

Meanwhile , we have to take care that the system objects of dm_document type should not get r_aspect_name field updated by our aspect.

Any more suggestions?

Thanks in advance.

msroth

There isn't anything in the query that would restrict the update to only dm_documents in a particular cabinet or folder. Does the user who is running the query have write access to all the dm_documents you expect them to? I would expect that you would want to constrain the update query some way so that it does not try to update all of the dm_documents in the repository. Use a FOLDER or CABINET predicate or constrain it by owner name.

Harish_Elango

@msroth / all,

How can i check if "defaultdatatypeaspect" is already attached to my Custom object type documents or not.

Pedro Maia

@Harish_Elango, you are not seriously expecting people to continue a thread from 11 years ago, are you? Please create a new thread asking your question.