Transaction bundle processing should include resource information in an audit entry

[d0roppe]

Is your feature request related to a problem? Please describe. When processing a transaction bundle today we only say weather the bundle was successful or if it failed, and how many resources were in the bundle. On a successful processing on a transaction bundle we should include the Resource type/id/version info for each resource processed in the bundle

[lmsurpre]

As part of this task, we should remove the current "data" section which consists of a "count" for each type of interaction within the bundle (without any indication of which resources are being acted upon).

Similar to https://github.com/IBM/FHIR/issues/3493 except for transaction bundles.

[lmsurpre]

Dag felt that it would also make the most sense to fire individual audit event messages for each interaction in the bundle (if successful) and only emit the event for the overall bundle if there was an error during processing. It might make sense to keep the "batch" section with these counts in just that error case. If so, the labels should be updated to better reflect that these were requested (and not completed):

• resources_read -> reads
• resources_created -> creates
• resources_updated -> updates
• resources_deleted -> deletes
• resources_executed -> executions

[lmsurpre]

I invoked a successful transaction bundle with 4 entries and checked the audit topic. I see 4 corresponding entries in kafka (good), but unfortunately the events are missing any information about which resources have been acted upon. For example, here is one of the 4 events:

{
    "action": "update",
    "eventTime": "2022-12-15 04:20:26.187",
    "eventType": "activity",
    "id": "1533da17-944f-4c7a-afa5-3cebb8fea969",
    "outcome": "success",
    "target": {
        "id": "a1c24725-4ce0-470a-b832-2114713b852f",
        "typeURI": "data/database",
        "addresses": [
            {
                "url": "/fhir-server/api/v4/",
                "name": "",
                "port": ""
            }
        ],
        "geolocation": {
            "city": "Washington DC",
            "state": "",
            "region": "USA",
            "annotations": [
            ]
        }
    },
    "typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event",
    "tags": [
    ],
    "attachments": [
        {
            "contentType": "application/json",
            "content": "rO0ABXQCHnsKICAgICJyZXF1ZXN0X3VuaXF1ZV9pZCI6ICIxNTMzZGExNy05NDRmLTRjN2EtYWZhNS0zY2ViYjhmZWE5NjkiLAogICAgImFjdGlvbiI6ICJVIiwKICAgICJzdGFydF90aW1lIjogIjIwMjItMTItMTUgMDQ6MjA6MjUuNjYxIiwKICAgICJlbmRfdGltZSI6ICIyMDIyLTEyLTE1IDA0OjIwOjI2LjE4NyIsCiAgICAiYXBpX3BhcmFtZXRlcnMiOiB7CiAgICAgICAgInJlcXVlc3QiOiAiL2ZoaXItc2VydmVyL2FwaS92NC8iLAogICAgICAgICJyZXF1ZXN0X3N0YXR1cyI6IDIwMAogICAgfSwKICAgICJkYXRhIjogewogICAgICAgICJyZXNvdXJjZV90eXBlIjogIk9wZXJhdGlvbk91dGNvbWUiCiAgICB9LAogICAgImV2ZW50X3R5cGUiOiAiZmhpci1idW5kbGUiLAogICAgImRlc2NyaXB0aW9uIjogIkZISVIgQnVuZGxlIFRyYW5zYWN0aW9uIHJlcXVlc3QiLAogICAgImxvY2F0aW9uIjogIjE3Mi4xNy4xNDkuMjAvMTcyLTE3LTE0OS0yMC5pYm0tazhzLWNvbnRyb2xsZXItZGVmYXVsdC1iYWNrZW5kLmt1YmUtc3lzdGVtLnN2Yy5jbHVzdGVyLmxvY2FsIgp9"
        }
    ],
    "initiator": {
        "id": "default@fhir-server",
        "typeURI": "compute/machine",
        "host": "fe80:0:0:0:d870:9bff:fe36:67c6%eth0,172.17.143.24,0:0:0:0:0:0:0:1%lo,127.0.0.1",
        "credential": {
            "token": "user-fhiruser"
        },
        "geolocation": {
            "city": "Washington DC",
            "state": "",
            "region": "USA",
            "annotations": [
            ]
        }
    },
    "observer": {
        "id": "fhir-server",
        "typeURI": "compute/node",
        "name": "IBM FHIR Server - Audit",
        "host": "fhir-server-6cff9d586-j4z5c",
        "geolocation": {
            "city": "Washington DC",
            "state": "",
            "region": "USA",
            "annotations": [
            ]
        }
    }
}

note that the url in that even is technically the right one for a transaction bundle ("/fhir-server/api/v4/")...however the intent of this work item is to ensure that the audit event contains the information for that actual resource(s) being acted upon.

I checked the attachment content as well, but there is no information in there about the actual resource interaction either:

??t{
    "request_unique_id": "1533da17-944f-4c7a-afa5-3cebb8fea969",
    "action": "U",
    "start_time": "2022-12-15 04:20:25.661",
    "end_time": "2022-12-15 04:20:26.187",
    "api_parameters": {
        "request": "/fhir-server/api/v4/",
        "request_status": 200
    },
    "data": {
        "resource_type": "OperationOutcome"
    },
    "event_type": "fhir-bundle",
    "description": "FHIR Bundle Transaction request",
    "location": "172.17.149.20/172-17-149-20.ibm-k8s-controller-default-backend.kube-system.svc.cluster.local"
}

Please address this part of the original description:

On a successful processing on a transaction bundle we should include the Resource type/id/version info for each resource processed in the bundle

I think it should be somewhat consistent with the batch event... so we may want to add the resource version info to that one as well (e.g. use a location like [resourceType]/[id]/_history/[vid] and not just [resourceType]/[id]