Integration Broker Integrity

The following table describes the audit queries and resolutions for this area:

Query Description Resolution

IBRK-01

Message parts referencing a message/version that does not exist.

Most likely caused by moving a container message in a project and not including all the part messages. Always make sure that when moving a container message in a project, every part message is also included if it doesn’t already exist in the target database.

IBRK-02

Rowset based messages referencing records that do not exist.

Most likely caused by moving a message in a project and not including records referenced in the message. Always make sure that when moving a rowset-based message in a project, every record that is not in the target database is also included in the project.

IBRK-03

Message parts must reference message/versions that are defined as part messages.

Most likely caused by moving a container message in a project and not including records referenced in the message. By definition, only part messages can be found in a container message. Always make sure that when moving a container message in a project, every part message contained is also in the project, unless the part message is already in the target database defined as a part message.

IBRK-04

Service operations need at least one version, the default.

Service operations cannot exist without a service operation version. These are separate managed objects and can therefore be added individually into a project. However, care must be taken when moving service operations in projects to always include the default version if it doesn’t already exist in the target database.

IBRK-05

Service references service operation(s) that do not exist

This audit reports any services that contain service operations that don't exist. Typically, this is caused when moving a service from one database to another by including the service in the project but not including all related service operations.

Care must be taken when moving services to always include the associated service operations in the project, unless the same service already exists in the target database.

IBRK-06

Service operation versions must have a valid Service operation

Service operations and service operation versions are separately managed objects. When moving service operation versions in a project, be sure to include the service operation with the same name unless the service operation already exists in the target database.

IBRK-07

Handlers must have a valid service operation.

Service operation handlers and service operations are separately managed objects. When moving handlers, be sure to include the related service operation unless the operation already exists in the target database.

IBRK-08

Routings must reference a valid service operation version.

Note: Routing IB_ADMIN_ROUTING is excluded because it is a dummy routing used during upgrade to 8.48.

Service operation routings and service operation versions are separately managed objects. When moving routings, be sure to include the related service operation version unless the operation version already exists in the target database.

IBRK-09

Routings must reference valid nodes

Service operation routings and nodes are separately managed objects. When moving routings, be sure to include any related Node that doesn’t exist in the target database.

IBRK-10

Routings must reference valid service operation handlers

Service operation routings and service operation Handlers are separately managed objects. When moving routings, be sure to include the related service operation Handlers that appear in the routing component unless the Handlers already exist in the target database.

IBRK-11

Routing parameters must reference valid transform application engine programs

Service operation routings reference application engine transform programs. When moving routings, be sure to include any referenced Application Engine programs unless the programs that appear in the routing parameter component already exist in the target database.

IBRK-12

Routing parameters must reference valid message/version combinations.

Service operation routings reference messages. When moving routings, be sure to include any referenced messages unless the messages that appear in the routing parameter component already exist in the target database.

IBRK-13

Service operation versions need to reference valid messages

Service operation versions reference messages. When moving versions in a project, be sure to include any referenced messages unless the messages that appear in the service operation or service operation versions component already exist in the target database.

IBRK-14

Service operation versions need to reference valid queues

Service operation versions reference Integration Broker queues. When moving versions in a project, be sure to include any referenced queues unless the queues that appear in the service operation or service operation versions component already exist in the target database.

IBRK-15

Service operation versions need to reference valid transform programs

Service operation versions reference application engine transform programs. When moving versions in a project, be sure to include any referenced application engine programs unless the programs that appear in the service operation versions component already exist in the target database.

IBRK-16

Service operation versions with validation turned on require each referenced message to have a schema defined

Service operations versions with validation turned on (see the Service Operations component), require all referenced messages to have schemas defined. When moving service operation versions that have validation turned on, include all referenced messages unless the referenced messages already exist in the target database with valid schemas. Also note that when moving messages in projects the related schemas are not brought along. These need to be moved using Data Mover scripts (PSIBMSGSCHEMA_IMP.DMS and PSIBMSGSCHEMA_EXP.DMS).

IBRK-17

Component interface handlers should reference valid component interfaces.

Service operation handlers that are of type CI reference component interfaces. When moving service operation handlers, be sure to also include any referenced component interfaces in the project unless the CIs already exist in the target database.

IBRK-18

Application class handlers should reference valid application packages

Service operation handlers that are of type Application Class reference application classes. When moving service operation Handlers, be sure to also include any referenced application classes in the project unless they already exist in the target database. Care must be taken to make sure that the referenced application class PeopleCode is also included in the project.

IBRK-19

Part messages need to have a schema defined.

When moving messages in projects, the related schemas are not brought along. The schemas need to be moved using Data Mover scripts (PSIBMSGSCHEMA_IMP.DMS and PSIBMSGSCHEMA_EXP.DMS). For part messages, having a schema is mandatory.

IBRK-20

Container messages need to have a schema defined.

When moving messages in projects, the related schemas are not brought along. These need to be moved using Data Mover scripts (PSIBMSGSCHEMA_IMP.DMS and PSIBMSGSCHEMA_EXP.DMS). For container messages, having a schema is mandatory.

IBRK-21

Operations with duplicate routings.

This audit reports service operations with multiple active routings where the sender and receiver node are identical. There should never be multiple active routings where the sender and receiver node are identical for a service operation.

Delete or inactivate one of the offending routings for each service operation.

IBRK-22

Operations with duplicate ANY routings

This audit reports service operations with multiple active routings where the sender node is set to ANY. There should never be multiple active routings where the sender node is set to ANY for a service operation.

Delete or inactivate one of the offending routings for each service operation.

You can change the status of one of the duplicate routings as follows: 

UPDATE PSIBRTNGDEFN
SET EFF_STATUS = 'I'
WHERE ROUTINGDEFNNAME = <NAME>
AND EFFDT = <EFFDT>

To delete a duplicate routing, select PeopleTools, and then Integration Broker, and then Service Utilities, and then Integration Broker Admin. On the Routings tab, find the routing to remove and remove it. Alternatively, you can run the following set of SQL statements: 

DELETE FROM PSIBRTNGDEFN
WHERE ROUTINGDEFNNAME = <NAME>
AND EFFDT = <EFFDT>

DELETE FROM PSIBRTNGSUBDEFN
WHERE ROUTINGDEFNNAME = <NAME>
AND EFFDT = <EFFDT>

DELETE FROM PSRTNGDFNPARM
WHERE ROUTINGDEFNNAME = <NAME>
AND EFFDT = <EFFDT>

DELETE FROM PSRTNGDFNCONPRP
WHERE ROUTINGDEFNNAME = <NAME>
AND EFFDT = <EFFDT>

IBRK-23

Operation with no Service Relationship

There should never be operations referencing services that don't exist. Typically, this is caused when importing a project containing a service operation that belongs to a service that does not exist in the target database.

Always make sure that the services that a service operation belongs to exist in the target database or are included in the import project.

All service operations must belong to at least one service.

IBRK-24

DMS Handler referencing invalid message

This audit identifies handlers of type Data Mover with a missing message. Certain Data Mover handlers require an associated message. When moving Data Mover handlers in a project, all related messages should also be included.

To resolve issues, locate the message(s) in the database that was used to create the handler. Import that message into the target database (where you ran SYSAUDIT).

If you can't locate the message, recreate the handler in the source database and then be sure to include both the handler and the related message in the project, and import the project.

IBRK-25

IB PSOPERATIONAC referencing a handlername that doesn't exist.

Service operation handler definitions refer to Application Classes that contain the PeopleCode logic that gets triggered when requests come in. This audit identifies service operation handlers that have a defined Application Class name, but the Application Class doesn't exist in the database.

To resolve issues, either copy the Application Package/Application Class referred to by the handler definition, or delete the service operation using the following SQL statement:

DELETE FROM PSOPERATIONAC 
WHERE IB_OPERATIONNAME = <NAME>

IBRK-26

IB Nodes with missing gateway definition.

You must specify the integration gateway that a node uses for integrations. On the Nodes-Connectors page, define the integration gateway to use for integrations in the Gateway ID field.

IBRK-27

Operation with no service name in PSOPERATION table

This audit identifies the service operation entries in PSOPERATION table which does not have the IB_SERVICENAME column set. To resolve this audit issues, run the Application Engine program – UPGPTSERVOPR. This Application Engine program has a step to fix entries in PSOPERATION with right service names.

IBRK-28

Application Service with no service defined.

This audit identifies the Application Service entries that do not have a defined IB Service. To resolve this audit issue, bring up the Application Service in the Application Services Designer and re-save the Application Service. This should re-build the Service and associated metadata.

IBRK-29

Application Service with no service defined.

This audit identifies the Application Service entries that do not have a defined Document. To resolve this audit issue, bring up the Application Service in the Application Services Designer and re-save the Application Service. This should re-build the Document and associated metadata.