CMSEntity之四，三类文件的处理

ProductHandler类是真正从product，product content和charging info转换为price plan，入口可以认为是processPricePlans方法。

首 先它调用getUnprocessedCntProductAssoc，这个方法的功能是：1.Get Unprocessed Content and Product associate VO from DB 2.Sort the unprocessed list。这个方法涉及到了ContentProductAssocVO，这里有个机制去判断一个ContentProductAssocVO是否已经被 处理过，逻辑上应该是先比较几个ID：IsmpContentId，IsmpProductId和OpFlag，如果相同，再比较时间戳。但是具体的逻辑 没细看。

获得Content and Product associate VO list后，processPricePlans继续调用processCntProductAssocList， 这个方法的功能是：Fetch all the content and product pair in the content_product_mapping table for this particular content_id。注意这里面提到了CONTENT_PROD_MAP table，这个表很重要。processCntProductAssocList方法调用fetchContent来获得ContentItemVO，注意fetchContent的参数是contentID。

然后processCntProductAssocList调用fetchProcducts， 这个方法有点复杂，它用参数返回好几个map（cntProducts，deletedCntProdMap和omittedCntProdMap，把哪 些product放到哪一个map里是更加opflag来判断的，另外，处理出错的情况都放到omittedCntProdMap里去。）。这个方法会调 用createPriceMethod，这个方法非常重要，它用来生成price method，在manufacture price plan和operation price plan里都能看见（method标签），它的参数有ChargingPolicyVO和ProductVO，前者保存的是电信的收费信息。该方法首先得到charg info的收费方式，在电信文档的附录D中有描述，包括BREW系统原有计费策略和与之相应的ISMP产品计费策略。这些策略一共有九种，但是在createPriceMethod里只处理了5种情况，不知道为什么。

在 fetchProducts的最后有一个逻辑，当OpFlag为delete时，把product放入deletedCntProdMap，如果 OpFlag不是delete，那就是add，但是在之前还要进行判断，如果要add的项也被包含在deletedCntProdMap（两者的 productID相同，也就是一个product既已经被包括在deletedCntProdMap，现在又要将其add），那么就要判断add的项和 delete的项两者的时间戳，如果要add项的时间戳要早于要delete项的时间戳，那就什么也不干（表示这个product最终是要被删除的），反 之，就将给product加入到cntProducts中。

processCntProductAssocList会调用fetchProducts两次，然后processCntProductAssocList调用prepareMfgPricePlan方 法，它的功能是：Prepare the MFG Price plan and generate the meta file. The ISMP price plan to BMC price plan mapping logic are locate inside this method. 说明这个方法很重要，manufacturer price plan文件就是由它构建的。