2009年7月24日星期五

CMSEntity之一,各种Job和VO

contentFetcherJob
ContentProcessorJob

ProductInfoFetchJob
ProductProcessJob

com.chinatelecom.ismp.contentpublish.req包的类ContentSyncNotifyReq

com.chinatelecom.ismp.contentpublish.ContentPublishedReqAdapter
com.chinatelecom.ismp.contentpublish包里的方法ContentPublishedReqAdapterSoapBindingImpl::contentSyncNotify

前 面的关系有点乱,到现在还没理清,按流程应该是ISMP先给BSG发一个contentSyncNotify(一个SOAP call),BSG收到这个notify后去解析它的内容,获得content description文件的存放地址和目录,但是现在还不知道是在哪里处理这个notify的,本以为是在 com.qualcomm.bss.bsg.cms.servicelaye.BSGWebServiceServlet处理这个notify的,但是看 了这个类的doGet方法,感觉这个方法没有处理notify。CMSWebServices和CMSEntity两个工程里面都没找到,这个暂且放下, 以后再找找。

目前看com.chinatelecom.ismp.contentpublish。ContentPublishedReqAdapterSoapBindingImpl::contentSyncNotify是处理notify的(但不知道它是如何被调用的,好像用了一个axis2的东西,google了一下,这是Apache的一个包,但是它是干什么用的没细看)。
方法contentSyncNotify使用了contentSyncNotifyReq, 这个类其实无甚特别,但是其中有一段代码搞得我很迷惑:static{... ...},这段代码和org.apache.axis.description有关,不知道是干嘛的,留到后面再研究。然后 contentSyncNotify调用saveContentSyncInfo将得到的信息保存到数据库中,这个应该是content description文件的存放地址和目录。

com.qualcomm.bss.bsg.cms.parser是一个接口,类CDParserImpl实现了这个接口,里面有个方法:parseCDFile,这个方法就是用来解析content description文件的。
com.qualcomm.bss.bsg.cms.process.ContentAdaptor类中的方法:invokeProcess,调用了parseCDFile。
然 后com.qualcomm.bss.bsg.cms.job.ContentFetcherJob的方法execute中会调用 contentAdaptor.invokeProcess。这个ContentFetcherJob是从StatefulJob继承的类,也就是它是一 个Quterz的类,周期性地执行,
在com.qualcomm.bss.bsg.cms.servicelayer.BSGCMSServlet的init方法中会创建ContentFetcherJob,并对它进行调度。

所 以这几步的流程 是:com.qualcomm.bss.bsg.cms.servicelayer.BSGCMSServlet.init->com.qualcomm.bss.bsg.cms.job.ContentFetcherJob.execute->com.qualcomm.bss.bsg.cms.process.ContentAdaptor.invokeProcess
->com.qualcomm.bss.bsg.cms.CDParserImpl.parseCDFile。

在 ContentAdaptor类里有个方法fetchFile,这个方法其实就是从给定的地址中用FTP去取文件,invokeProcess调用 fetchFile去获取content description文件,content description文件的地址,在前面提到,content description文件的存放地址和目录已经保存在数据库中了。

content description文件解析完后,ContentAdaptor::invokeProcess会调用fetchZipFile去获取zip文件,这 些zip文件就是product_info.map,content_product.map和charge_info.map文件了。文件被取回 后,ContentAdaptor::invokeProcess还调用了:
batchStatusVO.setProcStatCodeID(Constants.BATCH_STATUS_SAVED);
updateBatchStatus(batchStatusVO);
这 两个调用貌似很重要,因为zip文件取回后就要进入下一步的处理,即将这三个map文件解析并将相应的内容填到数据库中,但是处理三个map文件也是一个 job,即ContentProcessJob,这个job也是在 com.qualcomm.bss.bsg.cms.servicelayer.BSGCMSServlet.init被创建初始化并调度的。也就是说, 它一直周期性地试图去处理三个map文件,但是并不是时时刻刻都有map文件需要处理(因为不是每时每刻都有产品要提交到BMC上去),所以当有新的 map文件被取回后,必须要有一种方法通知ContentProcessJob,现在有新的map文件需要处理了。这个方法应该就是 ContentAdaptor::invokeProcess在取回map文件后,向数据库里写了某些信息,就相当于置了某些标志位,然后 ContentProcessJob在处理过程中首先是查询数据库,获得信息得知是否有新的map文件需要处理。

com.qualcomm.bss.bsg.cms.job.ContentProcessorJob
com.qualcomm.bss.bsg.cms.process.invokeProcess
com.qualcomm.bss.bsg.cms.process.getSuitableBatch

ISMPItemVO
ContentItemVO

没有评论:

发表评论