Clarity Service Management

Expand all | Collapse all

Offline Reporting - Synchronization

Jump to Best Answer
  • 1.  Offline Reporting - Synchronization

    Posted 03-02-2016 04:37 AM



    Sorry for many posts on offline reporting, we are setting up this and want to use CABI with offline reporting SDM instance


    I have setup the publication with the below settings. On Offline SDM Instance, I have created a incident and after by replication job executes now i can see two incidents with the same number on my offline sdm server. Is this intended behaviour or should I select the Probhit subscriber changes or do we have any setting which restrict creation of any tickets in offline sdm instance.





  • 2.  Re: Offline Reporting - Synchronization

    Posted 03-02-2016 05:56 AM

    Do someone is accessing your sdm application replicated instance? as this need to be set to offline reporting mode to avoid users been eventually be able to create ticket there.

    except of the above or if you change data manually in the database the option above will not have impact.

    Do the ID of the record are the same or only the ref_num?


    You must start from an empty database on the subscriber and apply the initial snapshot.

    if this is done replication index will prevent to have duplicate record

    How did you get the mdd on your replicated server?

  • 3.  Re: Offline Reporting - Synchronization

    Posted 03-02-2016 06:52 AM


    I my self was doing some testings and accidently created ticket in offline reporting instance.


    I have set my sdm offline to offline reporting in nx but how do we avoid this accidently creating of tickets.


    The ID is different only the ref_num is same



    First i restored the MDB and then used the subcription which will run every 2 hours.

  • 4.  Re: Offline Reporting - Synchronization

    Posted 03-02-2016 09:41 AM

    Hi Sharath,


    We used to prefer using merge replication, but with the advent of 14.1,  for both 12.9 and 14.1 releases - transactional is preferred.    We have an automation tool for this as well in 14.1, as well as manual approach if that's preferred.


    Secondly, if Prod's MDB is restored into offline MDB,  then you will surely have some tables that are not suited for Offline SDM and some configuration options that carried over from Prod SDM instance.  This is normally not a good thing. Check out the Review CA Service Management Deployment  section in the above link.   It has explicit instructions on the tables that you need to backup (including data) on the SDM offline MDB first,  before you restore prod MDB on top of Offline MDB.    Then you need to restore these tables back again to preserve the integrity of the offline SDM configuration.   

    Finally, if you start a normal procset, there's really nothing preventing anyone to create tickets in the offline env. That's why the offline procset was developed so that it'd satisfy CABI/ODBC reporting needs. 




  • 5.  Re: Offline Reporting - Synchronization

    Posted 03-02-2016 09:47 AM

    Hi Raghu,


    Thanks for the info, and on the last point, we have set the procset to OFFLINE_Reporting as depcited below. Will this also allow fore creating of the tickets in the offline SDM instance?


    [ default procset OFFLINE_REPORTING ]


    Im looking for a solution, where the offline sdm should not have a way for the creating of the data directly



  • 6.  Re: Offline Reporting - Synchronization
    Best Answer

    Posted 03-02-2016 02:37 PM

    using the OFFLINE_REPORTING procset will in fact prevent  any users to be able to access this instance to create ticket

    so you must be good now


  • 7.  Re: Offline Reporting - Synchronization

    Posted 03-02-2016 08:07 PM

    Hi Sharath,


    In a close review of your screenshot, it appears that it is Merge Replication (Synchronization Direction is not available in Transactional Replication).  Given the support we have for Transactional Replication, maybe you could go with this approach as opposed to Merge ?    Previous posts' links are the ones for Transactional.