Issues in extending custom service

An existing custom class /service/dsl was to be extended with the new class /service/dsl/new as part of a promotion to be offered to customers. Using Developer Center SCE, the tool did not complain when the new class was committed and a price plan was even committed(that is, using Pricing Center) using this new service. However, when CM/DM is restarted, and Developer Center restarted, the new service inexplicably disappeared from SCE.

The pin_deploy utility was tried to create this new service, but pin_deploy threw an error and the DM pinlog showed the following: " sdo_create_new_tti:no parent for /au_service/dsl/new".

Just to verify the process, a totally new service was created and extended using SCE, and the services were created without errors. After checking out the objects that were created, I found out that BRM creates two objects for each new service class, one as /service and another one as /au_service. For example, if /service/local is created, the objects that are created in the database are /service/local and /au_service/local.

The existing custom service class /service/dsl was examined and found out that it does not have its corresponding /au_service object. The other custom service classes don't have their corresponding /au_service objects as well and threw a similar error when extended. The standard services that comes with BRM has their /au_service objects however, and can be extended.

To resolve this issue, a /au_service/dsl object was inserted into the database with the POID value being the increment of the /service/dsl object POID and all other fields remain identical. After this was done, the new service was able to commit to the database without errors, either using SCE or pin_deploy.

Now, the question is "How come those objects were missing if BRM was supposed to create them automatically whenever a new service class is created?"
The answer is: Who knows?!? The solution is there and the problem seems to be in no danger of repeating itself. :) Although most probably it was caused by enabling/disabling audit trails.