The company I’m working in is using ASAP for service provisioning, and just like the rest of the products newly acquired by oracle it has almost no documentation, and generally is treated as a black box by most of the support crews. I’m starting to believe that this a strategy deviced by Oracle to insure your perpetual dependence on them, Luckily Earlier I was lucky enough to attend two ASAP courses taught by a young mexican ASAP developer who used to be working in Metasolv (the company that created ASAP) from the very beginning, during these two courses that guy went in details about many undocumented work arounds and tweaks to the system that can ensure system stability and efficiency, however since this is out of my scope I’m going to try to reuse this information in the support schema.
First of all ASAP is contains mainly 4 main components:
- SRP (Service Request Processor)
- SARM (Service Activation Request Manager)
- NEP (Network Element Processor)
- Control Server/ Fork agent/ORBIX
The work order is received from the CRM to the SRP that breaks it down to CSDLs that are later on breaken down fruther into ASDLs by the SARM, finally the NEP handles every ASDL converting I into commands that can be telneted to the NE.
Each of those components has its own DB that can be accessed using a different user (most deployments place them all on a single DB on separate schema.
The most important tool to be used while supporting ASAP is its developer/admin guide, 2 pdf files that include everything there is about a standard ASAP deployment.
Since we don’t have any documentation about the ASAP deployment we have I have to start by reverse engineering it to figure out which of the components are installed and which aren’t, also which tables are being used, Logically I’m going to start my analysis from the SRP, going through the schema I found out that most of the tables aren’t used, only the table translating work orders to CSDLs is filled and the rest are empty. So I moved a step down to the SARM.
TBL_CSDL_CONFIG had a description of every CSDL, which is really valuable as we didn’t have to this moment any idea what each CSDL does, now at least we know when a CSDL fails what it does exactly
TBL_NE_EVENT contains all the events received from the nep, it can be used to trace the current state of the neps.
TBL_NEP_ASDL_PROG contains the transalation between ASDL to the equivilant java classes, and although this is not directly useful it is however nice to have as this way we can direct our 3rd line to the class that is missbehaving rather than relying on them completely.
TBL_SRQ is more than valuable it includes the state of each CSDL in each SRQ (work order), with the status of it. In our deployment several CSDLs/ASDLs fails every few minutes unexplicably maybe this would help not to mention a simple query can give us a general view of the system and the ability to take stop issues before they actually happen
0 : HELD
By using this query you can have an idea about the number of the SRQs that have failed during a certain time frame.
SELECT COUNT(*) FROM tbl_srq
where srq_stat=13 AND
Next phase will start from TBL_SRQ_CSDL, and move on from there but today I’m going to stop here.