Enable auditing in Service Manager

Auditing enables the system to create a separate audit record each time a user makes a change to a record and saves it to the database. The document describes how to enable and configure auditing so that if any records are added/deleted/modified in a table, it is captured and recorded by the application.

Auditing captures all modifications made to a record in any Service Manager table at the application level.

However, auditing does not capture any information if the changes to a table are made at the database level.

The following configuration of auditing captures information about any modifications made to records in a Service Manager table:

1. Login to service Manager as administrator

2. Go to System Navigator > Tailoring > Audit > Turn Auditing On/Off

Check the following options:
Do you want to audit development changes?
Do you want to keep backups of Changes?

3. Create a new Audit Specification as follows:

System Navigator > Tailoring > Audit > Audit Specification > enter the name of the table to audit in the filename field

4. Specify the Unique A field as the unique key for that particular table

The screenshot below shows an example audit record for the probsummary table:

5. Update the format control record for that particular table as follows:

Type fc in the command line > search for filename > Check the Save Copy check box > select Javascript > select more Options > select Show Expanded Form

Add: true
update: true
delete: true

In the text box line 1:
vars.$filetmp=new SCFile(“<filename>”);

The screenshot below shows an example of the javascript tab for the format control probsummary:

6. Select Subroutines in the format control > select more options > select Show Expanded Forms

Put in the following details in a new line:

Application Name: audit.compare
Names: file
Values: $file
Names: second.file
Values: $filetmp

Add msg ID: true
Delete:true
Add:true
Update:true

The screenshot below shows an example of the subroutines tab for the format control probsummary:

7. Save the format control record

8. Disconnect from the client and connect again for changes to take effect

All audit records are stored in a table called audit. This table can be accessed as follows:

Type db in command line > type in the table name as audit > type in the format name as audit > search

The audit record generated for any changes made to a table will look something like this:

The audit record will have information about the following:

1. Name of the file to which the changes are made and saved (label=filename)
2. Timestamp of the change(label=Recorded)
3. Name of the filed in the table that is changed(label=Field Name)
4. Value of the field before the change was made(label=Old Scalar)
5. Operator/user who made the change(label=falcon)

Advertisements

Oracle 12c single-tenant / pluggable database support for SM 9.4x

There are three distinct types of databases in Oracle Database 12c.

• A single-tenant database: This is a self-contained set of data files, control files, redo log files, parameter files, and so on, that include all of the Oracle metadata (the definition of ALL_OBJECTS, for example), Oracle data, and Oracle code (such as the code for DBMS_OUTPUT), in addition to all of the application metadata, data, and code. This is the only type of database in releases prior to version 12c.
• A container or root database: This is a self-contained set of data files, control files, redo log files, parameter files, and so on, that only include the Oracle metadata, Oracle data, and Oracle code. There are no application objects or code in these data files—only Oracle-supplied metadata and Oracle-supplied code objects. This database is self-contained in that it can be mounted and opened without any other supporting physical structures.
• A pluggable database: This is a set of data files only. It is not self-contained. A pluggable database needs a container database to be “plugged into” to be opened and accessible. These data files contain only metadata for application objects, application data, and code for those applications. There is no Oracle metadata or any Oracle code in these data files. There are no redo log files, control files, parameter files, and so on—only data files associated with a pluggable database. The pluggable database inherits these other types of files from the container database it is currently plugged into.

So you can see that “single-tenant database” is one type of the three distinct types of databases in Oracle Database 12c, and “pluggable database” is another type of the three.

“single-tenant database” is the only type before 12c, so it is automatically supported.

“pluggable database” is also supported. It is based on two reasons:

1. there are the following text in the chapter 2 of that pdf:

How Is a Pluggable Database Different?
From the perspective of a developer, a pluggable database is no different from a single-tenant database. The application connects to the database in exactly the same way it would connect to a single-tenant database in earlier releases. The earlier examples of creating connections, using shared servers, and using dedicated servers all still apply. The differences lie in the underlying architecture–that of a single instance for many pluggable databases, and the resulting reduced resource utilization on the server and the ease of management for the DBA.
2. The design of SM RTE makes it treats the implementation details of the ORACLE database architecture as a black box.

Attachments uploaded do not save to Service Manager

In some cases a tailored format appears to prevent uploaded attachments from saving to Service Manager. This problem is sporadic and appears to be exclusive to the Web Client and not the Windows Client. If encountered the steps taken to see the problem are to upload the attachment and save. When the record displays the attachment is not present.

Upon further examination it might be seen that there are multiple attachment widgets on the affected format using Visible Conditions to determine which one is displayed to the user.

In scenarios where this has been seen the solution was to modify the format so only one attachment wizard was present. For example, in one case there were two Notebooks each with its own attachment widget. The solution was to tailor the format so that only one attachment widget was needed since both attachment wizards were – in essence – uploading to the same target. The updated format – using the single attachment widget displayed to all users – no longer experienced the problem with attachments not saving.

Click New button redirect to search page in Knowledge documents list

Steps to Reproduce:

1. login to SM
2. Queue: Knowledge Document
3. All Knowledge Documents are listed.
4. New

Current behavior: Screen to “Search Knowledge Document” opens
Expected behavior: Screen to open a new Knowledge Document opens

Cause

Object “kmdocument” misses some entries.

Fix

1. Command db
2. Table: Object
3. File name: kmdocument
4. Search
5. Tab page: Manage Queues
6. Field: Add/open application
7. add the value: kmdocument.open
8. Field: Allow add condition
9. Add the value:
not (null(contents($G.km.environment))) and (index(“SysAdmin”, $lo.ucapex)>0 or index(“KMAdmin”, $lo.ucapex)>0 or contribute in $G.km.environment=true)
10. Save this Object
11. relogin and test again.

Mandanten on array field is not working

Set up scmandant on table incidents with Mandanten Field Name assignment. This is an array field and it is not working when setting up a scsecuritygroup record with an assignment group as Excluded Value List.

What solution will fit in our implementation when using this array field assignment (table incidents) in combination with een Excluded Value List?

1. open the file: scmandant
2. seach the file name “incidents”
3. Exclude field as “1 in assignment” for only checking on the first value of the array field assignment and Mandant Field Name as “assignment”
4. Save/add, then logout

Installation of SM9.50 fails on RHEL7 with signal 11

Signal 11 segment fault might happen in RHEL7.x OS when running smserver, the call stack trace in log file would look like:

RTE I [Curr.Frame][Next Frame][ProgCountr]

RTE I [0xF6154A68][0xF6154A88][0xF7E67BE3] libsm.so::UnixOSFunctionsImpl::PrintStackWithInfo(int, void*, void*)(+0x002B)(0xF7FD4400,0x0000000B,0xF6154B0C)

RTE I [0x00000000][0xF6294931] libc.so.6::__strcasestr_sse42(+0x0571)

Cause

This is a known ORCALE 32 BIT client issue, the detail information can be found at:

https://community.oracle.com/thread/3897829

https://access.redhat.com/solutions/2123951

Fix

Create an empty file/etc/sysconfig/64bit_strstr_via_64bit_strstr_sse2_unaligned as root user.

Error Viewing Closed Service Request Tickets in Service Request Catalog

When attempting to open certain Interaction tickets in Service Request Catalog, users are experiencing the following error (The string of random characters varies):

Retrieving c206QCM8PjpzbTpAIzw+OlNENTAwOTE0OkAjPD46ZjNkZDI2OTM= from the server failed. Try again.

This issue seems to be resolved for support tickets, but some service catalog tickets are still erroring out.

Some of the issue seems to come from catalog items that have been inactivated. However, it seems like there might be a mandatory field missing on this one as well.

Solution

The Catalog ID of some of the items in the Cart’s is no longer valid. Once we updated the problematic Carts with the correct Catalog ID, the problem goes away.