MicroServices - Edit History

Introduction

The Edit History microservice is used to log data related to changes made by operators in the CMS. The logged data is added when an item of a mediatype is created, updated or deleted, also when a relationship is created or deleted with the referred item. The stored data may also be read by operators using this microservice.

Both of these functions are available through an API, which will be detailed later.

Prerequisites

Docker
MibConfig via ENVVAR
MongoDB

Required Configuration Files

Some configurations are required by the microservice and for the service that consumes it service and provides the data to be logged.

MibEditHistoryMicroServiceClientConfig

ApiUrl, string: path where the microservice is served.
MaxCallErrors, int: maximum number of times that the microservice is called in case of unsuccesful response.
Timeout, int: maximum response time tolerated from the microservice in seconds.

MibEditHistoryMicroServiceServerConfig

IsLogEnabled, bool: includes all the data information to be added in the EditHistory DB in the log produced by the microservice operations.
EnsureIndex, bool: creates indexes in the Edit History BD.

MibObjectNotificationConfig

NotificationAssemblyName, string: "MediaiBox.Cms.MicroServices.EditHistory.Listener".
NotificationClassFullName, string: "MediaiBox.Cms.MicroServices.EditHistory.Listener.MibEditHistoryListener".

MibLogConfig

MibMongoDBConfig see more

MibCmsFrontEndServerBaseConfig

UseEditHistoryMicroService, bool: enables the use of the edit history microservice (must be True).

Required configuration file at Cms.FrontEnd:

MibEditHistoryMicroServiceClientConfig
MibCmsFrontEndServerBaseConfig

Required configuration file at Cms.Api:

MibEditHistoryMicroServiceClientConfig
MibObjectNotificationConfig

Required configuration file at Cms.MicroService:

MibEditHistoryMicroServiceServerConfig
MibLogConfig
MibMongoDBConfig

Using with DocumentDB AWS

To use DocumentDB with the MongoDB driver, it is necessary to pay attention to the points below:

Will need to apply the UseTls setting in MibMongoDBConfig to establish a secure connection.
Will need to apply the ClientCertificate setting in MibMongoDBConfig to validate the connection. If not informed, a FileNotFoundException will be released.
It is possible to define whether the service should validate revoked certificates. To apply validation, set CheckCertificateRevocation setting in MibMongoDBConfig to true.

If CheckCertificateRevocation is true, the connection process will call the ClientCertificateSelectionCallback. ClientCertificateSelectionCallback can be used to apply validations as needed. By default, Mib only checks if there are any errors logged in this callback. If it exists, an InvalidOperationException will be released.

There are two ways to set your callback logic:

In all constructors of MibMongoDb it is possible to pass a RemoteCertificateValidationCallback.
In the MibMongoDb class there is a SetServerCertificateValidationCallback method to inform the callback.

For more information about the process follow documentation links:

API Routes

Save

POST: edithistory/v1/save/{mediatype}/{registerId}
Parameters:

mediatype: mediatype name of the register which changes would be logged
registerid: id of the register which changes would be logged
SaveInformation, body:

{
    "userid": "int",
    "repositoryObject":{
        "modifiedFields":[
        {
            "name": "string",
            "newvalue": "string",
            "originalvalue": "string"
        }],
        "addedRelations":[
        {
            "mediatype": "string",
            "id": "int"
        }],
        "removedRelations":[
        {
            "mediatype": "string",
            "id": "int"
        }]    
    },
    "operationtype": "int"     
}

userId: id of the user who made that change
repositoryObject: holds the description in lists for changes in fields (name of the field, old and new value) and for changes in relations (mediatype and id of the item). Each list may be null if there is no change in their subject.
operationType: enum value described in MediaiBox.Core.Audit.MibAuditObjectChanges.ChangeOperationType, which may be:
```
{
    Added,
    Changed,
    Removed,
    AddedRelation,
    RemovedRelation
}
```

SaveBatch

POST: edithistory/v1/save/batch

SaveInformation, body:

[
  {
    "id": 0,
    "mediaType": "string",
    "userId": 0,
    "repositoryObject": {
      "modifiedFields": [
        {
          "name": "string",
          "originalValue": "string",
          "newValue": "string"
        }
      ],
      "addedRelations": [
        {
          "mediaType": "string",
          "id": 0
        }
      ],
      "removedRelations": [
        {
          "mediaType": "string",
          "id": 0
        }
      ],
      "auditInformation": {
        "instanceId": 0,
        "requestId": "string",
        "pageKey": "string",
        "source": 0,
        "tags": [
          "string"
        ],
        "hiddenFields": [
          "string"
        ]
      }
    },
    "operationType": 1
  }
]

id: id of the register which changes would be logged
mediatype: mediatype name of the register which changes would be logged
userId: id of the user who made that change
repositoryObject: holds the description in lists for changes in fields (name of the field, old and new value) and for changes in relations (mediatype and id of the item). Each list may be null if there is no change in their subject.
operationType: enum value described in MediaiBox.Core.Audit.MibAuditObjectChanges.ChangeOperationType, which may be:
```
{
    Added,
    Changed,
    Removed,
    AddedRelation,
    RemovedRelation
}
```

Read

POST: edithistory/v1/read/{mediatype}/{registerId}?page={page}&limit={limit}
Parameters:

mediatype: mediatype name of the register which logged changes would be read
registerid: id of the register which logged changes would be read
page: pagination value
limit: maximum number of items per request (if not informed or the value is less than or equal to zero, a default limit of 10 will be applied)
ReadInformation, body:

{
    "relateds":[
    {
        "name":"string",
        "relationType":"int",
        "relationColumn":"string"
    }],
    "readPermissions":[
        "string",
        "string",
        "string"
    ]
}

readPermissions: list of mediatype names that the user has the permission to read.
relateds: list of mediatypes related to the main mediatype, with their name, type of relation and relationship column.
- relationType is an enum described in MediaiBox.Cms.MicroServices.EditHistory.Model.RelationshipType, which may be:
```
{
    Direct,
    DirectInverse,
    LinkObjects,
    RelationshipTable
}
```

Troubleshooting

If the register changes are note being shown in the drawer or dashboard correctly, checking if the record is present in the MongoDB may be a good lead:

✅ If it is present:
- The issue may be in retrieving the information
- Check the configuration in Cms.FrontEnd:
  - Are the MicroService endpoints being called?
    - ✅ Yes → Check:
      - MibMongoDBConfig on the MicroService and the MongoDB environment
      - GET methods on the MicroService
    - ❌ No → Check:
      - UseEditHistoryMicroService on the Cms.FrontEnd must be set to true in MibCmsFrontEndServerBaseConfig
      - MibEditHistoryMicroServiceClientConfig on the Cms.FrontEnd must point to a working environment
❌ If it is NOT present:
- The issue may be in saving the information
- Check the configuration in Cms.Api and Cms.MicroService
  - Are the MicroService endpoints being called?
    - ✅ Yes → Issue is likely in the MicroService logic, MibMongoDBConfig, or the MongoDB environment
    - ❌ No → Check:
      - Configuration in Cms.Api
      - Assembly set in MibObjectNotificationConfig
      - Save process in Cms.Api or Core.MibObjects

Table of Contents