Should we create a json string out of auditPayload and then store it in payload field.

No need to specify the full package name since now there's no name clash between AuditEvent and AuditEventV2

You can just use the diamond operator <> since you already gave the type specification via the Map declaration: Map<String, String> auditPayload = new HashMap<>();

Removed

See comment re. not needing the full package name

Removed

auditPayload.toString() will invoke AbstractMap#toString() which looks like JSON but isn't. Echoing @anurag-gujral, shouldn't we be serializing this as JSON instead?

Am now serializing

This coincidentally works since PredixEventProcessor and PredixEventMapper are part of the same package, but it might break if trying to wire an instance of PredixEventMapper elsewhere. Perhaps add an @Component annotation to the PredixEventMapper class above?

Added

This has not been addressed, frank can you please comment?

@anurag-gujral, @FrankGasparovic has addressed this above.

We should probably add at least one test for auditing input validation failures: { ... , PublisherType.APP_SERVICE, CategoryType.MALICIOUS, EventType.INVALID_INPUTS, Classifier.FAILURE }

If it's outside the scope of the current release, we should at least create a story to track this.

Added story for this in audit feature

The story for CategoryType.MALICIOUS /input validation has been added to the backlog.

This isn't necessary since the audit-sdk dependencies have already been added to the POMs. All that's necessary is to change the version in the <audit-sdk.version>0.0.x-SNAPSHOT</audit-sdk.version> line in the top-level POM.

That said, we should add something like the following to the public Maven profile in this POM to exclude compilation of all src and test classes in the com.ge.predix.acs.audit package:

            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-compiler-plugin</artifactId>
                        <version>3.3</version>
                        <configuration>
                            <excludes>
                                <exclude>com/ge/predix/acs/audit/*</exclude>
                            </excludes>
                            <testExcludes>
                                <testExclude>com/ge/predix/acs/audit/*</testExclude>
                            </testExcludes>
                        </configuration>
                    </plugin>
                </plugins>
            </build>

To allow this import to be resolved, we probably want to explicitly add the EventHub SDK dependency to the predix Maven profile of acs/service/pom.xml:

                <dependency>
                    <groupId>com.ge.predix.eventhub</groupId>
                    <artifactId>predix-event-hub-sdk</artifactId>
                    <version>${predix-event-hub-sdk.version}</version>
                </dependency>

added

Contrary to what we thought, this line to instantiate this.eventProcessor doesn't seem necessary (runs without a NullPointerException for me)

Removed

Slightly better since it passes a mock object to process(...) instead of null:

    @Test
    public void testPredixEventProcess() throws AuditException, EventHubClientException {
        AuditEvent mockAuditEvent = Mockito.mock(AuditEvent.class);
        AuditEventV2 mockPredixEvent = Mockito.mock(AuditEventV2.class);
        Mockito.when(mockedMapper.map(mockAuditEvent)).thenReturn(mockPredixEvent);

        Assert.assertTrue(this.eventProcessor.process(mockAuditEvent));
        Mockito.verify(mockedClient).audit(mockPredixEvent);
    }

Added

May next time when we commit we can make hardcoded string to private final String members

Only used in one place at the moment.

This does not look correct, the map function should throw an exception instead of just logging.

We are only constructing well formed JSON in this map method with potentially "garbage" as values in the JSON. I don't see a reason that we should throw this exception.

Also the values in the auditPayload cannot be null, so we shouldn't have problems.

Need proper exception handling rather than catching the exception and returning boolean

Boolean is required because of the way we created the tests for the AuditEventProcessor. Also we shouldn't add the throws at the interface level because different implementations of AuditEventProcessor may not use the Predix-Audit SDK.