Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

Many a times certain requirement occurs wherein we have to monitor the activities of MDM . Activities like record being modified , record rollback , record syndication, repository status change and few other MDM events. Manually monitoring these activities is not possible.In such a scenario , monitoring MDM activities through some other mechanism is more feasible.

Here the concept of listening from MDM events comes into picture. We can call it a MDM Listener activity.This can be achieved using a MDM Java API  - 'EventDispatcher' .

'EventDispatcher' is a class in Java which would help to listen (ie raise alert on the registered event) so that related processing can be done.

Simple MDM events like record checkout , record modified , record rolled back , record syndicated can be listened . Also , events like repository loaded , repository unloaded can be listened.

This class is responsible for dispatching all events coming from one specific MDM server to all event listeners subscribed in this dispatcher.We just need to register the specific MDM server so that it can handle the events listened by this dispatcher.

In order to define the set of notifications available on the dispatcher it should be registered to one or several groups of notifications .Notifications which indicate Repository level activities , server level activitites or Data level activities.

The Steps for subscribing the listener and starting it are as follows:

Create a main class with a method which will hold the listener and create another class which will extend AbstractServerListener Interface if we want to listern to Server activities , AbstractRepositoryListener Interface if we want to listern to Repository activities or extend AbstractDataListener Interface if we want to listern to record level activities.

If all these 3 activities are to be listened to , then 3 different classes extending above interfaces individually should be declared.

These classes ,which extend the required interface, can override methods of the respective interface for further processing.

In the below example we will create a main class 'EventListenerExample' with a method 'EventMethod' .The second class extending the interface would be  RepositoryEventListener with method 'repositoryStatusChanged' which overrides the 'repositoryStatusChanged' method of AbstractRepositoryListener Interface.

To run this , few parameters are required ie server name , repository name , and the user name authorised to access them.

1.  If we were to listen MDM repository events, then the Listener class would be as below

 

import com.sap.mdm.notification.event.RepositoryStatusEvent;

import com.sap.mdm.notification.AbstractRepositoryListener;

class RepositoryEventListener extends AbstractRepositoryListener

{

     public void repositoryStatusChanged(RepositoryStatusEvent event)

      {

          //Print repository status

      }

}

2. In the main class , in method 'EventMethod' ,create an instance of EventDispatcher as below and set the server name

      EventDispatcher eventDispatcher = EventDispatcherManager.getInstance().getEventDispatcher(serverName);


3. Add listeners to Event Dispatcher class

     For this , first we need to initialize listeners.For initializing listeners , the class which extends the reqiured listener interface is created as above.

 

    RepositoryEventListener repositoryListener = new RepositoryEventListener(); // Creating instance of Listener class

4. Once the listener instance is created , add the listener object initialized ablove to the EventDispatcher so that these events can be captured.

 

     eventDispatcher.addListener(reposListener);

5. Register (subscribe) for all type of notifications for the event

 

RepositoryEventRegistrationSet reposRegSet = new RepositoryEventRegistrationSet(); 

reposRegSet.addEventType(RepositoryEventRegistrationSet.IMPORT_EVENTS); 

reposRegSet.addEventType(RepositoryEventRegistrationSet.SYNDICATION_EVENTS); 

reposRegSet.addEventType(RepositoryEventRegistrationSet.ALL_REPOSITORY_EVENTS);

 

RepositorySessionContext repSessionContxt = new RepositorySessionContext(serverName,repositoryName,userName);

 

eventDispatcher.registerRepositoryNotifications(reposRegSet, repSessionContxt,"");


With this the listener is triggered. But this listener activity wouldn't continue for long.To keep MDM listener running for sometime , add a loop as below which would run for 5 mins.As per requirement the time condition can be changed . Now ,the listener would continue for 5 mins

while (count < 5 * 60)

{

   try

   {

      Thread.sleep(1000);

   }

   catch (InterruptedException e)

  {

      e.printStackTrace();

   }                                    

  count++;

}

So , now with the code in place , a call to the method EventMethod will set the Listener and this thread will continue for 5 mins (since we have kept the while loop running for 5 mins) . In this while , any change in repository status would be captured by the listener and if any loggers are written in this method then these can be seen.

Once the entire execution is done , one of the important step is to terminate the EventDispatcher instance only in standalone applications.Don't terminate EventDispatcher if it runs in a Web AS because this instance may be shared by other threads.

EventDispatcherManager.getInstance().terminateEventDispatcher(serverName);

Now, the complete code would look like below

public class EventListenerExample

{

public void EventMethod (String para_serverName , String para_repositoryName , String para_userName ) {

     UserSessionContext userSessionContext;

     SessionManager sessionManager;

 

     userSessionContext = new UserSessionContext(para_serverName,para_repositoryName, "" ,para_userName);

 

     userSessionContext.setTrustedConnection(true);

 

     sessionManager = SessionManager.getInstance(); 

     sessionManager.createSession(userSessionContext,SessionTypes.USER_SESSION_TYPE,"");

     EventDispatcher eventDispatcher = EventDispatcherManager.getInstance().getEventDispatcher(para_serverName);

 

     RepositoryEventListener repositoryListener = new RepositoryEventListener();

     eventDispatcher.addListener(reposListener);

      RepositoryEventRegistrationSet reposRegSet = new RepositoryEventRegistrationSet(); 

     reposRegSet.addEventType(RepositoryEventRegistrationSet.IMPORT_EVENTS); 

     reposRegSet.addEventType(RepositoryEventRegistrationSet.SYNDICATION_EVENTS); 

     reposRegSet.addEventType(RepositoryEventRegistrationSet.ALL_REPOSITORY_EVENTS);

 

     RepositorySessionContext repSessionContxt = new RepositorySessionContext(para_serverName,para_repositoryName,para_userName); 

     eventDispatcher.registerRepositoryNotifications(reposRegSet, repSessionContxt,"");

     while (count < 5 * 60)

     {

        try

        {

           Thread.sleep(1000);

        }

        catch (InterruptedException e)

       {

           e.printStackTrace();

        }                                    

       count++;

     }

     EventDispatcherManager.getInstance().terminateEventDispatcher(para_serverName);

     sessionManager.destroySessions(userSessionContext);

     }

}

class RepositoryEventListener extends AbstractRepositoryListener

{

     public void repositoryStatusChanged(RepositoryStatusEvent event)

      {

          //Print repository status

      }

}

This can now be written in a web module and further triggered as a Web service and used or a call to this web module can be done from Web dynpro Java applciation.

Limitation of 'EventDispatcher' MDM Java API :

MDM event notification is not a guarantee delivery system. In addition, there are known limitations and deficiency. For example, AbstractDataListener.recordAdded is not trigger if a record is created through import.

Another important limitation would be with termination of EventDispatcher instance.EventDispatcher instance shoudln't be terminated if it runs in a Web AS because this instance may be shared by other threads.It should be terminated only in standalone application.

5 Comments
Labels in this area