View Source

Tworzenie systemowego audytu

Aby dodać kolejny audyt do systemu, należy:

Do klasy dodać odpowiednią wartość np. AUDIT_CUSTOM_TEST.
W klasie AuditCategories należy dodać nowy utworzony typ audytu w metodzie zwracającej kategorię tego audytu.

Jeżeli audyt jest dodawany do kontrolera/servletu i jest dostęp do obiektu HttpServletRequest, to należy dodać fragment:

@RequestMapping( "audit" )
@ResponseStatus( HttpStatus.OK )
public void test( HttpServletRequest request )
{
    // czasochłonne operacje

    request.setAttribute( "audit", AuditBuilder.getInstance()
        .type( AuditTypes.AUDIT_CUSTOM_TEST )
        .success( true )
        .params( ImmutableMap.of( "param1", "paramValue" ) ) // parametry audytu
        .build() );
}

System sam obliczy sobie czasy wykonania zapytania, wyciągnie zalogowanego użytkownika oraz adres IP.
Możemy też skorzystać z odpowiednich metod, zamiast ustawiać pole z sukcesem:

AuditBuilder.getInstance().type(AuditTypes.AUDIT_CUSTOM_TEST).buildSuccess();
AuditBuilder.getInstance().type(AuditTypes.AUDIT_CUSTOM_TEST).buildFailure();

Jeżeli audyt jest dodawany w innym miejscu, niż kontrolery/servlety, to należy dodać fragment.

Date started = new Date();

// czasochłonne operacje ...

ManualAuditBuilder.getInstance() // ManualAuditBuilder pozwala na ustawienie dodatkowo użytkownika, czas trwania audytu i adres IP
    .type( AuditTypes.AUDIT_CUSTOM_TEST )
    .started( started )
    .username( username ) // jeżeli nie ma dostępu do requesta, lecz znany jest użytkownik
    .success( true )
    .params( ImmutableMap.of( "param1", "paramValue" ) )
    .build()
    .log();

Należy samemu obliczyć czas wykonania audytu, ustawić ręcznie użytkownika i adres IP (jeżeli jest taka informacja).

Do tłumaczeń systemowych typu SERVER należy dodać wpisy z tłumaczeniami dla typu audytu (klucz identyczny jak typ audytu), oraz dla nazwy parametru (AUDIT_PARAM_ + nazwa parametru wielkimi literami). Przykładowo:
AUDIT_CUSTOM_TEST=Dowolna nazwa audytu AUDIT_PARAM_PARAM1=Dowolna nazwa parametru audytu
6. W przypadku, w którym wartości parametrów audytu wymagają przetworzenia przed wyświetleniem należy dodać odpowiedni Formatter rozszerzający klasę com.suncode.pwfl.audit.formatter.Formatter z modułu plusworkflow-audit.
Sytuacje, w których powinno się dodać własny formatter to:
tłumaczenie nazwy procesu/zadania
pobranie imienia i nazwiska użytkownika (zamiast loginu)
pobranie jakiejś nazwy, którą użytkownik może zdefiniować w customowych plikach tłumaczeń
przetłumaczenie wartości logicznej
przetłumaczenie jakiejś nazwy np. typ indeksu klasy dokumentów, typ uprawnienia, konfiguracji itp

Klasa Formatter posiada już niektóre metody pozwalające na tłumaczenie wybranych parametrów audytu.

Jeśli tworzymy audyt operacji, w której zostają zmienione jakieś parametry np. należy w parametrach audytu pokazać zmianę parametru w formacie stara_wartość > nowa_wartość. Jeśli wartości mają zostać w jakiś sposób przetworzone to zalecam przekazać je do formattera w postaci "stara_wartość;nowa_wartość", ponieważ metody w klasie Formatter mają obsługę dostosowaną to wartości oddzielonych średnikiem.

Tworzenie audytu wdrożeniowego

Aby dodać wdrożeniowy audyt, należy:

Jeżeli audyt jest dodawany do kontrolera/servletu i jest dostęp do obiektu HttpServletRequest, to należy dodać fragment:

@RequestMapping( "audit" )
@ResponseStatus( HttpStatus.OK )
public void test( HttpServletRequest request )
{
    // czasochłonne operacje

    request.setAttribute( "audit", AuditBuilder.getInstance()
        .type( "AUDIT_CUSTOM_TEST" ) // typ audytu jako zwykły tekst
        .success( true )
        .params( ImmutableMap.of( "param1", "paramValue" ) ) // parametry audytu
        .build() );
}

System sam obliczy sobie czasy wykonania zapytania, wyciągnie zalogowanego użytkownika oraz adres IP.

Jeżeli audyt jest dodawany w innym miejscu, niż kontrolery/servlety, to należy dodać fragment.

Date started = new Date();

// czasochłonne operacje ...

ManualAuditBuilder.getInstance()
    .type( "AUDIT_CUSTOM_TEST" ) // typ audytu jako zwykły tekst
    .started( started )
    .username( username ) // jeżeli nie ma dostępu do requesta, lecz znany jest użytkownik
    .success( true )
    .params( ImmutableMap.of( "param1", "paramValue" ) )
    .build()
    .log();

Należy samemu obliczyć czas wykonania audytu, ustawić ręcznie użytkownika i adres IP (jeżeli jest taka informacja).

Do dowolnego zarejestrowanego tłumacza o scope SERVER należy dodać wpisy z tłumaczeniami dla typu audytu (klucz identyczny jak typ audytu), oraz dla nazwy parametru (AUDIT_PARAM_ + nazwa parametru wielkimi literami). Przykładowo:
AUDIT_CUSTOM_TEST=Dowolna nazwa audytu AUDIT_PARAM_PARAM1=Dowolna nazwa parametru audytu
Internacjonalizacja (I18N)

Creating a system audit

To add another audit to the system you need to:

Add an appropriate value to the class, e.g. AUDIT_CUSTOM_TEST.
In the AuditCategories class, add the new created audit type in the method that returns the category of this audit.

If the audit is added to the controller/servlet and there is access to the HttpServletRequest object, add a fragment:

The system will calculate the query execution times itself, pull the logged-in user and IP address.

We can also use the appropriate methods instead of setting the field with success:

@RequestMapping( "audit" )
@ResponseStatus( HttpStatus.OK )
public void test( HttpServletRequest request )
{
    // time-consuming operations

    request.setAttribute( "audit", AuditBuilder.getInstance()
        .type( AuditTypes.AUDIT_CUSTOM_TEST )
        .success( true )
        .params( ImmutableMap.of( "param1", "paramValue" ) ) // audit parameters
        .build() );
}

AuditBuilder.getInstance().type(AuditTypes.AUDIT_CUSTOM_TEST).buildSuccess();
AuditBuilder.getInstance().type(AuditTypes.AUDIT_CUSTOM_TEST).buildFailure();

If the audit is added somewhere other than the controllers/servlets, add a snippet.

Date started = new Date();

// time-consuming operations

ManualAuditBuilder.getInstance() // ManualAuditBuilder additionally allows you to set the user, audit duration and IP address
    .type( AuditTypes.AUDIT_CUSTOM_TEST )
    .started( started )
    .username( username ) // if there is no access to the request, but the user is known
    .success( true )
    .params( ImmutableMap.of( "param1", "paramValue" ) )
    .build()
    .log();

You should calculate the audit execution time yourself, set the user and IP address manually (if there is such information).

For system translations of the SERVER type, add translation entries for the audit type (key identical to the audit type), and for the parameter name (AUDIT_PARAM_ + parameter name in capital letters). For example:
AUDIT_CUSTOM_TEST=Any audit name AUDIT_PARAM_PARAM1=Any audit parameter name
In cases where audit parameter values need to be processed before displaying, you should add an appropriate Formatter extending the com.suncode.pwfl.audit.formatter.Formatter class from the plusworkflow-audit module.
Situations in which you should add your own formatter are:
translation of the process/task name
getting user's name (instead of login)
getting some name that user can define in custom translation files
translation of a boolean value
translation of some name, e.g. document class index type, permission type, configuration, etc.

The Formatter class already has some methods to translate selected audit parameters.

If we create an audit of the operation, in which some parameters are changed, for example, it is necessary in the audit parameters to show the change of the parameter in the format old_value > new_value. If the values are to be processed in some way, I recommend passing them to the formatter in the form "old_value;new_value", because the methods in the Formatter class have support adapted to values separated by semicolons.

Creating an implementation audit

To add a implementatio

If the audit is added to the controller/servlet and there is access to the HttpServletRequest add a fragment:

@RequestMapping( "audit" )
@ResponseStatus( HttpStatus.OK )
public void test( HttpServletRequest request )
{
    // time-consuming operations

    request.setAttribute( "audit", AuditBuilder.getInstance()
        .type( "AUDIT_CUSTOM_TEST" ) // audit type as plain text
        .success( true )
        .params( ImmutableMap.of( "param1", "paramValue" ) ) // audit parameters
        .build() );
}

The system will calculate the query execution times itself, pull the logged-in user and IP address.

If the audit is added somewhere other than the controllers/servlets, add a snippet.

Date started = new Date();

// time-consuming operations

ManualAuditBuilder.getInstance()
    .type( "AUDIT_CUSTOM_TEST" ) // audit type as plain text
    .started( started )
    .username( username ) // if there is no access to the request, but the user is known
    .success( true )
    .params( ImmutableMap.of( "param1", "paramValue" ) )
    .build()
    .log();

You should calculate the audit execution time yourself, manually set the user and IP address (if there is such information).

To any registered interpreter with scope SERVER, add translation entries for the audit type (key identical to the audit type), and for the parameter name (AUDIT_PARAM_ + parameter name in capital letters). For example:
AUDIT_CUSTOM_TEST=Any audit name AUDIT_PARAM_PARAM1=Any audit parameter name
Internationalization (I18N)