普外科 外科手術(shù)科室質(zhì)量與安全管理指標統(tǒng)計表及普元啟動服務失敗的解決方法

臨床手術(shù)科室醫(yī)療質(zhì)量與安全管理指標統(tǒng)計分析表（1月份）科室普外科科主任（簽名）填表日期2017年3月1日序號指標內(nèi)容與同期比變化趨勢1重點疾病病種名稱總例數(shù)死亡例數(shù)2周與1月內(nèi)再住院例數(shù)平均住院日平均住院費用（1）急性彌漫性腹膜炎208.026114.5下降（2）急性胰腺炎2010.78675.4上升（3）（4）（5）（6）2重點手術(shù)病種名稱總例數(shù)死亡例數(shù)術(shù)后(15天內(nèi))非預期再手術(shù)平均住院日平均住院費用（1）腹腔鏡下膽囊切除術(shù)0011.28966上上（2）胃切除術(shù)0下降（3）直腸切除術(shù)0下降（4）胰腺部分切除術(shù)2002920519上升（5）（6）（7）（8）4手術(shù)并發(fā)癥與患者安全監(jiān)測指標(1)擇期手術(shù)后并發(fā)癥發(fā)生率0%（肺栓塞0例、深靜脈血栓0例、敗血癥0例、出血或血腫0例、傷口裂開0例、猝死0例、呼吸衰竭0例、骨折0例、生理/代謝紊亂0例、肺部感染0例、人工氣道意外脫出0例）(2)產(chǎn)傷發(fā)生率%(3)因用藥錯誤導致患者死亡發(fā)生率0%(4)輸血/輸液反應發(fā)生率0%(5)手術(shù)過程中異物遺留發(fā)生率0%(6)醫(yī)源性氣胸發(fā)生率0%(7)醫(yī)源性意外穿刺傷或撕裂傷發(fā)生率0%6臨床路徑管理(1)病種名稱腹股溝疝，開展5例，入組率80%，完成率%；(2)病種名稱下肢靜脈曲張，開展2例，入組率50%，完成率%；(3)病種名稱，開展例，入組率%，完成率%；(4)病種名稱，開展例，入組率%，完成率%；(5)病種名稱，開展例，入組率%，完成率%；7單病種質(zhì)量監(jiān)測指標另附單病種統(tǒng)計報表8急危重癥病人管理指標急危重癥病人1人次，搶救1人次，搶救成功率100%9手術(shù)后感染例數(shù)010圍手術(shù)期預防性抗菌藥使用合理11住院超過30天患者人數(shù)212工作量統(tǒng)計出院患者261人次，手術(shù)94人次。13科室分析指標變化趨勢意見同期相比，急性胰腺炎病例交前有上升，這個與醫(yī)院條件改善，服務水平相關(guān)，胰腺手術(shù)交前上升，還需要繼續(xù)保持。備注：以上指標中凡屬于本科室內(nèi)容，請按要求認真規(guī)范填寫，一式兩份（科室留存一份，報質(zhì)控科一份），每月5號前報質(zhì)控科。重點手術(shù)及重點病種目錄、部分指標解讀和計算公式參見《三級綜合醫(yī)院評審標準(2011年版)實施細則》第七章日常統(tǒng)計學評價。

臨床手術(shù)科室醫(yī)療質(zhì)量與安全管理指標統(tǒng)計分析表（2月份）科室普外科科主任（簽名）填表日期2017年3月1日序號指標內(nèi)容與同期比變化趨勢1重點疾病病種名稱總例數(shù)死亡例數(shù)2周與1月內(nèi)再住院例數(shù)平均住院日平均住院費用（1）急性彌漫性腹膜炎007.76773下降（2）急性胰腺炎001011473上升（3）（4）（5）（6）2重點手術(shù)病種名稱總例數(shù)死亡例數(shù)術(shù)后(15天內(nèi))非預期再手術(shù)平均住院日平均住院費用（1）腹腔鏡下膽囊切除術(shù)009.68743降低（2）胃切除術(shù)001933130上升（3）直腸切除術(shù)0028.633330上升（4）胰腺部分切除術(shù)0000上升（5）（6）（7）（8）4手術(shù)并發(fā)癥與患者安全監(jiān)測指標(1)擇期手術(shù)后并發(fā)癥發(fā)生率0%（肺栓塞0例、深靜脈血栓0例、敗血癥0例、出血或血腫0例、傷口裂開0例、猝死0例、呼吸衰竭0例、骨折0例、生理/代謝紊亂0例、肺部感染0例、人工氣道意外脫出0例）(2)產(chǎn)傷發(fā)生率%(3)因用藥錯誤導致患者死亡發(fā)生率0%(4)輸血/輸液反應發(fā)生率0%(5)手術(shù)過程中異物遺留發(fā)生率0%(6)醫(yī)源性氣胸發(fā)生率0%(7)醫(yī)源性意外穿刺傷或撕裂傷發(fā)生率0%6臨床路徑管理(1)病種名稱腹股溝疝，開展4例，入組率75%，完成率%；(2)病種名稱下肢靜脈曲張，開展1例，入組率100%，完成率%；(3)病種名稱，開展例，入組率%，完成率%；(4)病種名稱，開展例，入組率%，完成率%；(5)病種名稱，開展例，入組率%，完成率%；7單病種質(zhì)量監(jiān)測指標另附單病種統(tǒng)計報表8急危重癥病人管理指標急危重癥病人1人次，搶救1人次，搶救成功率100%9手術(shù)后感染例數(shù)010圍手術(shù)期預防性抗菌藥使用合理11住院超過30天患者人數(shù)212工作量統(tǒng)計出院患者248人次，手術(shù)105人次。13科室分析指標變化趨勢意見住院患者有所下降，本月?lián)衿谑中g(shù)偏少，住院人次也可能因假期影響。備注：以上指標中凡屬于本科室內(nèi)容，請按要求認真規(guī)范填寫，一式兩份（科室留存一份，報質(zhì)控科一份），每月5號前報質(zhì)控科。重點手術(shù)及重點病種目錄、部分指標解讀和計算公式參見《三級綜合醫(yī)院評審標準(2011年版)實施細則》第七章日常統(tǒng)計學評價。

臨床手術(shù)科室醫(yī)療質(zhì)量與安全管理指標統(tǒng)計分析表（3月份）科室普外科科主任（簽名）填表日期2017年4月2日序號指標內(nèi)容與同期比變化趨勢1重點疾病病種名稱總例數(shù)死亡例數(shù)2周與1月內(nèi)再住院例數(shù)平均住院日平均住院費用（1）急性彌漫性腹膜炎007.57214上升（2）急性胰腺炎001111051下降（3）（4）（5）（6）2重點手術(shù)病種名稱總例數(shù)死亡例數(shù)術(shù)后(15天內(nèi))非預期再手術(shù)平均住院日平均住院費用（1）腹腔鏡下膽囊切除術(shù)009.989440.1上升（2）胃切除術(shù)0022.4384990上升（3）直腸切除術(shù)0027.6733236上升（4）胰腺部分切除術(shù)0000上升（5）（6）（7）（8）4手術(shù)并發(fā)癥與患者安全監(jiān)測指標(1)擇期手術(shù)后并發(fā)癥發(fā)生率00007692%（肺栓塞0例、深靜脈血栓0例、敗血癥0例、出血或血腫1例、傷口裂開0例、猝死0例、呼吸衰竭0例、骨折0例、生理/代謝紊亂0例、肺部感染0例、人工氣道意外脫出0例）(2)產(chǎn)傷發(fā)生率-%(3)因用藥錯誤導致患者死亡發(fā)生率0%(4)輸血/輸液反應發(fā)生率0%(5)手術(shù)過程中異物遺留發(fā)生率0%(6)醫(yī)源性氣胸發(fā)生率0%(7)醫(yī)源性意外穿刺傷或撕裂傷發(fā)生率0%6臨床路徑管理(1)病種名稱腹股溝疝，開展4例，入組率75%，完成率%；(2)病種名稱下肢靜脈曲張，開展1例，入組率100%，完成率%；(3)病種名稱，開展例，入組率%，完成率%；(4)病種名稱，開展例，入組率%，完成率%；(5)病種名稱，開展例，入組率%，完成率%；7單病種質(zhì)量監(jiān)測指標另附單病種統(tǒng)計報表8急危重癥病人管理指標急危重癥病人1人次，搶救1人次，搶救成功率100%9手術(shù)后感染例數(shù)010圍手術(shù)期預防性抗菌藥使用合理11住院超過30天患者人數(shù)212工作量統(tǒng)計出院患者285人次，手術(shù)130人次。13科室分析指標變化趨勢意見本月發(fā)生一例手術(shù)并發(fā)癥，手術(shù)后出血，再次手術(shù)，應注重原因分析及整改。腹腔鏡膽囊切除手術(shù)量交前有明顯上升，胃腸手術(shù)需要繼續(xù)保持增長。備注：以上指標中凡屬于本科室內(nèi)容，請按要求認真規(guī)范填寫，一式兩份（科室留存一份，報質(zhì)控科一份），每月5號前報質(zhì)控科。重點手術(shù)及重點病種目錄、部分指標解讀和計算公式參見《三級綜合醫(yī)院評審標準(2011年版)實施細則》第七章日常統(tǒng)計學評價。

臨床手術(shù)科室醫(yī)療質(zhì)量與安全管理指標統(tǒng)計分析表（4月份）科室普外科科主任（簽名）填表日期2017年5月2日序號指標內(nèi)容與同期比變化趨勢1重點疾病病種名稱總例數(shù)死亡例數(shù)2周與1月內(nèi)再住院例數(shù)平均住院日平均住院費用（1）急性彌漫性腹膜炎007.46509下降（2）急性胰腺炎009.89436下降（3）（4）（5）（6）2重點手術(shù)病種名稱總例數(shù)死亡例數(shù)術(shù)后(15天內(nèi))非預期再手術(shù)平均住院日平均住院費用（1）腹腔鏡下膽囊切除術(shù)009.379950上升（2）胃切除術(shù)0022.438490下降（3）直腸切除術(shù)0023.533844上升（4）胰腺部分切除術(shù)0000上升（5）（6）（7）（8）4手術(shù)并發(fā)癥與患者安全監(jiān)測指標(1)擇期手術(shù)后并發(fā)癥發(fā)生率0%（肺栓塞0例、深靜脈血栓0例、敗血癥0例、出血或血腫0例、傷口裂開0例、猝死0例、呼吸衰竭0例、骨折0例、生理/代謝紊亂0例、肺部感染0例、人工氣道意外脫出0例）(2)產(chǎn)傷發(fā)生率0%(3)因用藥錯誤導致患者死亡發(fā)生率0%(4)輸血/輸液反應發(fā)生率0%(5)手術(shù)過程中異物遺留發(fā)生率0%(6)醫(yī)源性氣胸發(fā)生率0%(7)醫(yī)源性意外穿刺傷或撕裂傷發(fā)生率0%6臨床路徑管理(1)病種名稱腹股溝疝，開展4例，入組率75%，完成率%；(2)病種名稱下肢靜脈曲張，開展2例，入組率100%，完成率%；(3)病種名稱，開展例，入組率%，完成率%；(4)病種名稱，開展例，入組率%，完成率%；(5)病種名稱，開展例，入組率%，完成率%；7單病種質(zhì)量監(jiān)測指標另附單病種統(tǒng)計報表8急危重癥病人管理指標急危重癥病人1人次，搶救1人次，搶救成功率100%9手術(shù)后感染例數(shù)010圍手術(shù)期預防性抗菌藥使用合理11住院超過30天患者人數(shù)212工作量統(tǒng)計出院患者人次，手術(shù)130人次。13科室分析指標變化趨勢意見本月出院人次及手術(shù)臺次交前有增加，。腹腔鏡膽囊切除手術(shù)量交前有明顯上升，胃腸手術(shù)需要繼續(xù)保持增長。備注：以上指標中凡屬于本科室內(nèi)容，請按要求認真規(guī)范填寫，一式兩份（科室留存一份，報質(zhì)控科一份），每月5號前報質(zhì)控科。重點手術(shù)及重點病種目錄、部分指標解讀和計算公式參見《三級綜合醫(yī)院評審標準(2011年版)實施細則》第七章日常統(tǒng)計學評價。

臨床手術(shù)科室醫(yī)療質(zhì)量與安全管理指標統(tǒng)計分析表（5月份）科室普外科科主任（簽名）填表日期2017年6月2日序號指標內(nèi)容與同期比變化趨勢1重點疾病病種名稱總例數(shù)死亡例數(shù)2周與1月內(nèi)再住院例數(shù)平均住院日平均住院費用（1）急性彌漫性腹膜炎008.57770上升（2）急性胰腺炎0011.110984上升（3）（4）（5）（6）2重點手術(shù)病種名稱總例數(shù)死亡例數(shù)術(shù)后(15天內(nèi))非預期再手術(shù)平均住院日平均住院費用（1）腹腔鏡下膽囊切除術(shù)018.39628上升（2）胃切除術(shù)0022..438490下降（3）直腸切除術(shù)0023.637322上升（4）胰腺部分切除術(shù)002953740上升（5）（6）（7）（8）4手術(shù)并發(fā)癥與患者安全監(jiān)測指標(1)擇期手術(shù)后并發(fā)癥發(fā)生率0.63%（肺栓塞0例、深靜脈血栓0例、敗血癥0例、出血或血腫1例、傷口裂開0例、猝死0例、呼吸衰竭0例、骨折0例、生理/代謝紊亂0例、肺部感染0例、人工氣道意外脫出0例）(2)產(chǎn)傷發(fā)生率-%(3)因用藥錯誤導致患者死亡發(fā)生率0%(4)輸血/輸液反應發(fā)生率0%(5)手術(shù)過程中異物遺留發(fā)生率0%(6)醫(yī)源性氣胸發(fā)生率0%(7)醫(yī)源性意外穿刺傷或撕裂傷發(fā)生率0%6臨床路徑管理(1)病種名稱腹股溝疝，開展4例，入組率75%，完成率%；(2)病種名稱下肢靜脈曲張，開展2例，入組率100%，完成率%；(3)病種名稱，開展例，入組率%，完成率%；(4)病種名稱，開展例，入組率%，完成率%；(5)病種名稱，開展例，入組率%，完成率%；7單病種質(zhì)量監(jiān)測指標另附單病種統(tǒng)計報表8急危重癥病人管理指標急危重癥病人1人次，搶救1人次，搶救成功率100%9手術(shù)后感染例數(shù)010圍手術(shù)期預防性抗菌藥使用合理11住院超過30天患者人數(shù)112工作量統(tǒng)計出院患者次，手術(shù)170人次。13科室分析指標變化趨勢意見本月出院人次及手術(shù)臺次交前有增加，腹腔鏡膽囊切除術(shù)出現(xiàn)術(shù)中出血，注意變化，分析整改原因，腹腔鏡膽囊切除手術(shù)量交前有明顯上升，胃腸手術(shù)需要繼續(xù)保持增長。備注：以上指標中凡屬于本科室內(nèi)容，請按要求認真規(guī)范填寫，一式兩份（科室留存一份，報質(zhì)控科一份），每月5號前報質(zhì)控科。重點手術(shù)及重點病種目錄、部分指標解讀和計算公式參見《三級綜合醫(yī)院評審標準(2011年版)實施細則》第七章日常統(tǒng)計學評價。

臨床手術(shù)科室醫(yī)療質(zhì)量與安全管理指標統(tǒng)計分析表（6月份）科室普外科科主任（簽名）填表日期2017年7月2日序號指標內(nèi)容與同期比變化趨勢1重點疾病病種名稱總例數(shù)死亡例數(shù)2周與1月內(nèi)再住院例數(shù)平均住院日平均住院費用（1）急性胰腺炎170010.112990下降（2）（3）（4）（5）（6）2重點手術(shù)病種名稱總例數(shù)死亡例數(shù)術(shù)后(15天內(nèi))非預期再手術(shù)平均住院日平均住院費用（1）腹腔鏡下膽囊切除術(shù)51009.4710430上升（2）（3）（4）胰腺部分切除術(shù)1002533863-（5）（6）（7）（8）4手術(shù)并發(fā)癥與患者安全監(jiān)測指標(1)擇期手術(shù)后并發(fā)癥發(fā)生率0.63%（肺栓塞0例、深靜脈血栓0例、敗血癥0例、出血或血腫1例、傷口裂開0例、猝死0例、呼吸衰竭0例、骨折0例、生理/代謝紊亂0例、肺部感染0例、人工氣道意外脫出0例）(2)產(chǎn)傷發(fā)生率-%(3)因用藥錯誤導致患者死亡發(fā)生率0%(4)輸血/輸液反應發(fā)生率0%(5)手術(shù)過程中異物遺留發(fā)生率0%(6)醫(yī)源性氣胸發(fā)生率0%(7)醫(yī)源性意外穿刺傷或撕裂傷發(fā)生率0%6臨床路徑管理(1)病種名稱腹股溝疝，開展4例，入組率75%，完成率%；(2)病種名稱下肢靜脈曲張，開展2例，入組率100%，完成率%；(3)病種名稱，開展例，入組率%，完成率%；(4)病種名稱，開展例，入組率%，完成率%；(5)病種名稱，開展例，入組率%，完成率%；7單病種質(zhì)量監(jiān)測指標另附單病種統(tǒng)計報表8急危重癥病人管理指標急危重癥病人1人次，搶救1人次，搶救成功率100%9手術(shù)后感染例數(shù)010圍手術(shù)期預防性抗菌藥使用合理11住院超過30天患者人數(shù)112工作量統(tǒng)計出院患者139人次，手術(shù)84人次。13科室分析指標變化趨勢意見本月各項指標較前有所下降，受到分科影響。發(fā)生再次手術(shù)一例，住院原因分析。備注：以上指標中凡屬于本科室內(nèi)容，請按要求認真規(guī)范填寫，一式兩份（科室留存一份，報質(zhì)控科一份），每月5號前報質(zhì)控科。重點手術(shù)及重點病種目錄、部分指標解讀和計算公式參見《三級綜合醫(yī)院評審標準(2011年版)實施細則》第七章日常統(tǒng)計學評價。普元啟動服務失敗的解決方法

當多個人同時使用一個數(shù)據(jù)庫的時候，啟動普元控制臺會一直停留在rcall，然后顯示一個超時的警告，那樣就需要修改一下普元的一個定時器配置項。

安裝目錄下\Primeton\Platform\apps_config\default\config中的一個user-config.xml文件將下列代碼中高亮字段中的true改為false即可

<modulename="Schedule">

<groupname="Default">

<!--IsSchedulerStart[optional,defaultto"true"],whethertostarttimerwhenapplicationstartsup-->

<configValuekey="IsSchedulerStart">true</configValue>

<!--DataSouceName[optional,defaultto"default"],datasoucename（mustbethesameasDataSource'sGroupname）->

<!--configValuekey="DataSouceName">default</configValue-->

</group>

</module>

當EOS啟動調(diào)試服務時，控制臺停留在RCALL后無反應一般是因為定時任務的表被鎖住的原因，可在plsqldeveloper中執(zhí)行以下語句：select'altersystemkillsession'''||b.SESSION_ID||','||c.SERIAL#||'''immediate;'fromv$locked_objectb,v$sessioncwhereb.SESSION_ID=c.SID將查詢結(jié)果復制到新的SQL窗口執(zhí)行，執(zhí)行完成后再啟動服務--解決EOS連接失敗無法啟動的問題--查看有沒有被鎖的對象

select*fromv$locked_object--查看被鎖的對象是哪張表select*fromdba_objectswhereobject_idin(selectt.OBJECT_IDfromv$locked_objectt)--select*fromdba_objectswhereobject_id=73713--從菜單欄進入Tools/Sessions，將Status='ACTIVE'andSid=被鎖對象id的記錄，點擊右鍵菜單中的Kill跟操作系統(tǒng)的兼容性有關(guān)，建議去下看ide\eclipse\plugins目錄下org.eclipse.swt.win32.win32.x86_3.2.0.和org.eclipse.swt_3.2.0兩個jar的版本，更換成高版本試試。提供清理eos開發(fā)過程中緩存清理的方法摘要：提供清理eos開發(fā)過程中緩存清理的方法。在eos開發(fā)過程中，經(jīng)常遇到新開發(fā)的代碼無法使用，右鍵部署之后依然使用原來的老舊代碼，非常影響開發(fā)速度。這里提供下清理緩存的方式，確定我們的最新代碼能夠被使用。對于分組開發(fā)過程中，各人代碼版本差異無法實現(xiàn)同樣的運行效果有特效。1.

刪除%EOS_HOME%\apps_config\default\work_temp下的所有文件和文件夾。如需使用平臺的各種日志請酌情備份logs下的內(nèi)容。2.

刪除%EOS_HOME%\apache-tomcat-7.0.54\work下的所有內(nèi)容，情況tomcat的緩存。3.

刪除%EOS_HOME%\apache-tomcat-7.0.54\webapps\default\WEB-INF\_srv\work\user下我們自己項目的內(nèi)容。慎重，別刪錯了，我們自己開發(fā)的。ESB修改默認端口61616windows操作系統(tǒng)下的默認的ICS服務（InternetConnectionSharing）默認占用了61616端口，因此要解決jms端口沖突的情況有兩種方式。方式一：

停止ICS服務。

命令行執(zhí)行“services.msc”,找到ICS服務，右鍵停止，并設置為以后手動啟動。方式二：修改ESB下JMS默認端口。

找到D:\Primeton\ESB\studio\server\EOS\_srv\config下的esb-mq-config.xml和fts-server-config.xml文件，分別修改如下內(nèi)容：

（esb-mq-config.xml)

<transportConnectors>

<transportConnectorname="openwire"uri="tcp://:61616"/>

</transportConnectors>

(fts-server-config.xml)<mqconfig>

<url>tcp://:61616</url>

<reConnectTime>5</reConnectTime>

<heartbeat_interval>1</heartbeat_interval>

</mqconfig>

如何修改Platform發(fā)布Webservice服務的命名空間摘要：如何修改Platform發(fā)布Webservice服務的命名空間（）為自己指定的名字。問題描述:Platform發(fā)布Webservice服務，在瀏覽器上查看wsdl，客戶想修改其中的命名空間，如下圖紅色框的內(nèi)容，想更換成自己的命名空間。適用環(huán)境:

PlatformV6及以上版本處理經(jīng)驗:

可以修改user-config.xml中的配置，將DefultNameSpace這行的注釋放開，修改為自己指定的值。<module

name="WebService">

<group

name="WSDL">

<!--<configValue

key="DefultNameSpace">/</configValue>-->

</group>

</module>應用被攔截，調(diào)用報錯無法訪問摘要：應用被攔截，調(diào)用報錯無法訪問場景描述：

test.html

放在

Tomcat

的

webapps/ROOT

目錄下，或者其他非default應用下該靜態(tài)

HTML

頁面中有一個超鏈接

<a

href=":8080/default/"

target="_blank">EOStest</a>在資源管理器中直接雙擊該文件，在瀏覽器打開后（file:///

協(xié)議），點擊該超鏈接可以正常訪問。但如果我通過

:8080/test.html

訪問該頁面（http://

協(xié)議），點擊該超鏈接時，直接報錯了，錯誤信息為：調(diào)用異常，請查看日志！而使用window.open沒有問題。<ahref="#"onclick="open_win();">EOStest</a>，

<scripttype="text/javascript">

functionopen_win()

{

window.open(":8080/default/skins/default/index.jsp")

}

</script>情況分析：獲取前后http頭，referer為不同應用之間的請求，那么可能被default給攔截了。解決辦法：去除攔截器：把apps_config\default\config\eos\handler-web.xml中的以下配置注釋掉，看看是否還會不會有問題：

<handlerid="HttpRefererWebInterceptor"sortIdx="3"pattern="/*"class="com.eos.access.http.security.HttpRefererWebInterceptor"/>摘要：EOS工程部署到JBOSS后報錯。分析日后初步確定為"\jboss-6.1.0.Final\common\lib\slf4j-api.jar"與"\jboss-6.1.0.Final\server\default\deploy\default.ear\default.war\WEB-INF\lib\slf4j-api-1.5.6.jar"沖突導致該問題已經(jīng)解決。方案如下：

修改jboss\server\default\deployers\jbossweb.deployer\META-INF\war-deployers-jboss-beans.xml

添加org.slf4j，以過濾該包代碼如下：<!--

Allow

for

war

local

class

loaders:

in

testing

-->

<bean

name="WarClassLoaderDeployer"

class="org.jboss.web.tomcat.service.deployers.WarClassLoaderDeployer">

<property

name="relativeOrder">-1</property>

<property

name="filteredPackages">javax.servlet,mons.logging,org.slf4j</property>

</bean>

然后重啟JBOSS服務器。原因分析：

jboss加載jar包順序問題。摘要：在最近修改SSO應用的時候，涉及到需要在jar包中讀取工程配置文件的問題。在jar包中，讀取配置文件，需要單獨處理。項目中的一些配置文件，如pertieslog4j.xml不想打包進jar。因為可能會修改其中的一些配置信息，打包進jar，就變得比較笨拙，不方便修改文件?？梢杂萌缦路绞剑瑢崿F(xiàn)在jar包中讀取外部配置文件。方法一：關(guān)鍵代碼。讀取properties文件方法：InputStream

ins

=

getClass().getResourceAsStream("/resource/perties");

但是log4j.xml又需要單獨處理：PropertyConfigurator.configure(System.getProperty("user.dir")

+

"/resource/log4j.xml");

方法二：配置文件perties和jiar包在同一個目錄下面：FileInputStream

inputStream1

=

new

FileInputStream("perties");

配置文件perties在jar包內(nèi)部：InputStream

inputStream2

=

a.class.getResourceAsStream("/perties");org.apache.axis2.AxisFault:WSDoAllReceiver:摘要：使用EOS7.2自動生成的客戶端代碼，在調(diào)用帶有安全頭部消息的webservice接口的時候，會經(jīng)常出現(xiàn)org.apache.axis2.AxisFault:WSDoAllReceiver:IncomingmessagedoesnotcontainrequiredSecurityheader的異常，可以照下文處理使用EOS7.2自動生成的客戶端代碼，在調(diào)用帶有安全頭部消息的webservice接口的時候，會經(jīng)常出現(xiàn)org.apache.axis2.AxisFault:WSDoAllReceiver:IncomingmessagedoesnotcontainrequiredSecurityheader的異常，表示傳入的消息不包含所需的安全報頭，經(jīng)過分析發(fā)現(xiàn)是該方法在第一次被調(diào)用后，已經(jīng)生成了一些安全校驗數(shù)據(jù)，ListenerManager.defaultConfigurationContext不為空，無法對新的請求進行安全數(shù)據(jù)的封裝，導致請求失敗，應該清空ListenerManager.defaultConfigurationContext應用環(huán)境，重新生成對應的安全校驗數(shù)據(jù)?？梢哉杖缦路绞竭M行處理。在使用客戶端代碼的方法中，加入ListenerManager.defaultConfigurationContext=null;用于清空運行環(huán)境，以對新的請求，作出新的安全設置。示例代碼片段：@Bizlet

publicMapsellOrderPriceUpdate(SellOrderImplsellOrderImpl,SellOrderDetailImpl[]sellOrderDetailImpls)throwsException{

ListenerManager.defaultConfigurationContext=null;

//重置axis2部分運行參數(shù)環(huán)境，用于新的請求

ZCOP_SERVICEStub.ZifSoChangein=newZCOP_SERVICEStub.ZifSoChange();

//輸入

ZifSoChangeResponseresponse=newZCOP_SERVICEStub.ZifSoChangeResponse();//輸出EOS在業(yè)務程序中獲取邏輯構(gòu)件執(zhí)行的SQL語句文章

>

huangxu@

>

文章詳情EOS在業(yè)務程序中獲取邏輯構(gòu)件執(zhí)行的SQL語句

huangxu@

發(fā)表于3個月前

來自話題

#應用開發(fā)平臺（EOSPlatform）#

·

90

瀏覽摘要：更改log4j的日志配置，使用類繼承方式，方法重寫，在程序中獲取邏輯流執(zhí)行SQL。配置文件：應用配置目錄/log4j-sys.xml(可根據(jù)實際情況使用更改具體配置文件)；更改log4j的日志配置，使用類繼承方式，方法重寫，在程序中獲取邏輯流執(zhí)行SQL。配置文件：應用配置目錄

/log4j-sys.xml

(可根據(jù)實際情況使用更改具體配置文件)；配置文件說明：config/log4j-deploy.xml

部署日志

記錄系統(tǒng)啟動、停止、構(gòu)件包部署、集群通知等信息的日志。config/log4j-trace.xml

跟蹤日志

Server引擎的調(diào)試日志，用于系統(tǒng)維護人員定位系統(tǒng)運行問題使用。config/log4j-sys.xml

系統(tǒng)日志

大粒度的引擎運行的入口、出口的日志，用于調(diào)用棧分析，可以進行性能分析使用config/log4j-engine.xml

引擎日志

細粒度的引擎運行日志，可以打印上下文數(shù)據(jù)，用于定位業(yè)務問題。記錄時機：頁面流(P)執(zhí)行、邏輯流(B)執(zhí)行、服務(S)執(zhí)行、Web服務(W)調(diào)用、定時任務(D)執(zhí)行、JSP(J)執(zhí)行、SQL(Q)執(zhí)行（超過時限者記錄）、運算邏輯(X)執(zhí)行（超過時限者記錄）；記錄格式：有固定格式[記錄時間][請求編號][P|B|S|W|D|J|Q|X(類型)][Begin|End|Exception|Run][全名][執(zhí)行時長][父全名][IP地址][登錄用戶ID][登錄用戶名][當前內(nèi)存總量][當前空閑內(nèi)存量][自定義信息]。配置文件log4j-sys.xml

，找到log.sys.sql開關(guān)，<levelvalue="off"/>off更改為all找到RollingFileAppender新建新類LimsLogOut繼承RollingFileAppender，重寫doAppend方法，方法參數(shù)LoggingEvent內(nèi)有屬性可區(qū)分SQL。截圖實例如下：由于該類記錄SQL日志為超過時限者記錄，時限默認設置為1000毫秒，很多sql執(zhí)行時間可能不需要1000毫秒，需進行更改，找到sys-config.xml配置文件，將屬性LogSqlWhenTimeout設置為1。部署配置文件，在新建類LIMSLogOut中可以處理SQL日志。多個EOS連接同一個數(shù)據(jù)庫出現(xiàn)定時器表鎖定的問題解決方案文章

>

bigdabao

>

文章詳情多個EOS連接同一個數(shù)據(jù)庫出現(xiàn)定時器表鎖定的問題解決方案

bigdabao

發(fā)表于4個月前

來自話題

#應用開發(fā)平臺（EOSPlatform）#

·

260

瀏覽摘要：多個EOS連接同一個數(shù)據(jù)庫出現(xiàn)定時器表鎖定的問題解決方案問題描述：

如果多個EOS連接同一個數(shù)據(jù)庫，在server啟動的時候，會出現(xiàn)EOS_QRTZ_LOCKS鎖表的情況，導致Server啟動不成功解決方案：

多個環(huán)境連通過庫，容易出現(xiàn)定時器鎖表的問題，因為定時器默認情況下是啟動，可嘗試如下操作：<modulename="Schedule"><groupname="Default"><!--IsSchedulerStart[optional,defaultto"true"],whethertostarttimerwhenapplicationstartsup--><configValuekey="IsSchedulerStart">true</configValue><!--DataSouceName[optional,defaultto"default"],datasoucename（mustbethesameasDataSource'sGroupname）--><!--configValuekey="DataSouceName">default</configValue--></group></module>將顏色標記的true改為false（連同一個庫的每個環(huán)境都需要改）用戶session失效，ajax調(diào)用不能跳轉(zhuǎn)的解決方案文章

>

liucl

>

文章詳情用戶session失效，ajax調(diào)用不能跳轉(zhuǎn)的解決方案(PrimetonEOS)

liucl

發(fā)表于9個月前

來自話題

#應用開發(fā)平臺（EOSPlatform）#

·

341

瀏覽摘要：在某客戶項目支持過程中發(fā)現(xiàn)session失效后，ajax還能繼續(xù)調(diào)用，原因是在攔截器雖然能攔截到ajax調(diào)用，也做了跳轉(zhuǎn)到index.jsp的操作，但由于是ajax調(diào)用，在index.jsp中并不能完成跳轉(zhuǎn)，頁面沒有任何變化，所以不能正常跳轉(zhuǎn)到登錄頁面，在abframe或其它項目可能也存在這種問題。場景一個基于Ajax技術(shù)的Web應用，采用的是多頁面方式，每個頁面內(nèi)部使用Ajax實現(xiàn)復雜業(yè)務邏輯之間的無刷新切換，使用了Struts來實現(xiàn)MVC。問題對于Ajax請求，只有在通過用戶驗證無誤之后才能對請求作出響應。如果用戶長時間不做操作導致Session過時之后才發(fā)出請求，則此時應該跳轉(zhuǎn)到出錯頁面，提示用戶重新登錄。對于非Ajax請求，可以自定義異常并針對此異常設置相應的出錯頁面。在用戶信息驗證失敗的時候直接拋出此異常即可，web容器會自動捕捉到此異常并且顯示出錯頁面；但是，對于Ajax請求，則不會如期待的那樣自動跳轉(zhuǎn)到出錯頁面。若不錯特殊處理，Ajax請求的回調(diào)函數(shù)會得到意想不到的數(shù)據(jù)而導致程序出錯。分析對于一個Ajax的應用，每一次客戶端和服務器的數(shù)據(jù)交互，可以看成是在一個由客戶端的XMLHttpRequest和服務器端的Servlet(這里假設用Servlet響應Ajax請求)組成的閉合管道。解決在Filter中，判斷當前用戶是否處理登錄狀態(tài)，如果session已經(jīng)失效則調(diào)用response.getWriter.write("session_time_out");修改eos-ajax.js內(nèi)容，判斷返回的ajax.responseText的內(nèi)容是否為"session_time_out"，如果相等，則認為session已經(jīng)失效并調(diào)用top.location="auth/login.jsp"；注意eos-ajax.js是平臺js庫文件，所以像"auth/login.jsp"這樣的項目路徑最后采用配置的方式?？偨Y(jié)對于Ajax的請求，其數(shù)據(jù)流是封閉的，服務器發(fā)送給在客戶端的數(shù)據(jù)都被XMLHttpRequest對象所獲得。本文通過從Filter中發(fā)出javascript代碼讓其在客戶端得到執(zhí)行，從而可以在session過時驗證用戶信息失敗之后，讓客戶端自動跳轉(zhuǎn)到登錄頁面，與非Ajax請求時的客戶體驗相一致。對于Ajax請求，此方法進一步推廣，可以直接在服務器端發(fā)出javascript讓其在客戶端得到執(zhí)行。FTP大數(shù)據(jù)解決方案/articles/53c8c681e13823343b0000e3某客戶系統(tǒng)EOSPlatform流程數(shù)據(jù)丟失問題定位以及故障排除過程文章

>

yang-yong

>

文章詳情某客戶系統(tǒng)EOSPlatform流程數(shù)據(jù)丟失問題定位以及故障排除過程

yang-yong

發(fā)表于9個月前

來自話題

#應用開發(fā)平臺（EOSPlatform）#

·

88

瀏覽摘要：從解決問題的角度，我們不建議用戶直接將Connection的autoCommit設置為false，理由就是這樣破壞了數(shù)據(jù)庫連接；如果用戶需要將連接設置為false，則需要在用完連接后，將連接的狀態(tài)設置回去；或者直接在外層使用事務。一.客戶環(huán)境產(chǎn)品版本：EOSPlatform6.5服務器：Was7，4個節(jié)點的集群數(shù)據(jù)庫：Oracle11gJDK版本：1.6瀏覽器：IE7二.問題描述客戶環(huán)境上主要表現(xiàn)為通過邏輯流調(diào)用了BPS的服務，同時在邏輯流里面存在業(yè)務數(shù)據(jù)的操作，調(diào)用完邏輯流之后，流程數(shù)據(jù)和業(yè)務數(shù)據(jù)都丟失了，且整個過程沒有拋出異常，問題只是偶然重現(xiàn)，而且只能在正式環(huán)境上重現(xiàn)，測試環(huán)境始終沒有重現(xiàn)問題。三.問題分析定位過程1.熟悉客戶系統(tǒng)，了解問題重現(xiàn)方式，發(fā)現(xiàn)流程數(shù)據(jù)丟失需要客戶操作很多次才會出現(xiàn)一次，重現(xiàn)概率比較低；2.熟悉客戶代碼，發(fā)現(xiàn)客戶的邏輯流里面存在嵌套事務，且業(yè)務操作和流程操作在同一個事務里面，對流程的操作在一個子事務里面，邏輯流里面事務設置都是接收外部事務，且同步join方式執(zhí)行，沒有新開事務的情況，也不存在事務圖元不匹配的情況。3.分析報錯后的錯誤日志，發(fā)現(xiàn)錯誤是從事務同步器里面拋出來的，原因是queryWorkItemDetail報錯，即找不到工作項；正常的情況下，工作項不可能不存在，因為執(zhí)行到事務同步器的時候，事務必定已經(jīng)提交了，而此時查詢工作項肯定可以查詢到，但是目前的錯誤情況下，工作項不存在，即根據(jù)錯誤日志可以推斷出：事務已經(jīng)提交，但是數(shù)據(jù)沒有入庫。4.一開始對事務同步器理解不夠深刻，以為用戶調(diào)用了事務管理器的commit操作就會觸發(fā)同步器的方法，所以一開始懷疑用戶可能是事務使用不當，事務管理器的begin,commit不匹配之類的情況導致事務沒有正真提交，數(shù)據(jù)沒有入庫，所以需要驗證用戶是不是正真做了事務提交；5.驗證事務是不是正真做了提交：添加日志，在邏輯流里面的事務提交圖元前后打印出事務狀態(tài)，通過這個狀態(tài)就能判斷出事務管理器方法是不是存在不匹配的情況，同時在事務同步器里面打印出流程實例，活動實例，工作項實例的ID以及狀態(tài)，線程ID，請求ID之類的信息，方便問題重現(xiàn)后定位問題；我們判斷事務狀態(tài)的目的是：如果用戶正真做了提交，而數(shù)據(jù)沒有入庫，說明和產(chǎn)品存在一定關(guān)系，如果用戶沒有做事務提交，則是用戶代碼的問題，這樣我們就可以根據(jù)這個狀態(tài)進行2個大的方向定位。6.分析錯誤日志，對比正確情況和錯誤情況，發(fā)現(xiàn)打印出的事務狀態(tài)2種情況是一樣的，提交前是活動狀態(tài)，提交后是無事務狀態(tài)，說明用戶正真做了事務提交，即用戶使用的事務管理器begin，commit是匹配的；而且分析事務同步器里面打印出的流程實例，活動實例，工作項實例ID及狀態(tài)也都是一樣的，不存在異常情況，但是數(shù)據(jù)就是沒有進入到數(shù)據(jù)庫；7.由于事務管理器的使用方式?jīng)]有問題，問題又回到原點；后續(xù)只能通過大量重現(xiàn)問題，仔細分析日志，看還能否找到其他的蛛絲馬跡；由于這個問題是偶然重現(xiàn)，所以我們懷疑可能跟線程是否有關(guān)系，我們拿到大量的錯誤日志后，仔細查找這個問題是否和線程相關(guān)，發(fā)現(xiàn)他們存在一定的聯(lián)系，我們分析日志得到規(guī)律是：如果一個線程出錯后，后面所有由這個線程處理的邏輯流，流程數(shù)據(jù)都丟失，且有一個線程丟失的流程數(shù)據(jù)達8次之多；8.由于客戶現(xiàn)場不能對正式環(huán)境進行遠程調(diào)試，再加上測試環(huán)境一直重現(xiàn)不了，所以即使我們懷疑是線程問題，但是也無法進一步走下去。9.經(jīng)過討論會之后，我們開始定位數(shù)據(jù)庫連接是否存在問題；后續(xù)我們還是通過打日志的方式來判斷連接是否存在問題；我們在BPS獲取連接的入口打印連接的實現(xiàn)類，連接的狀態(tài)等信息；同時在事務管理器里面增加日志，在連接的setAutoCommit,close,commit方法上增加日志；10.分析日志：對比正確日志和錯誤日志可以發(fā)現(xiàn)，正確情況下，Connection的autoCommit狀態(tài)是true，錯誤情況下，Connection的autoCommit狀態(tài)是false；在正確情況下，Connection的autoCommit狀態(tài)是true，我們懷疑用戶的was環(huán)境存在問題，因為Connection受事務管理之后，autoCommit狀態(tài)一定是false，所以我們驗證用戶的環(huán)境是否是正常的；我們使用JSP做了最簡單的驗證：開啟事務，拿到連接，執(zhí)行第一條sql，然后執(zhí)行第二條sql，然后拋出異常，然后再執(zhí)行第3條sql，最后提交，拋出異常則回滾，部署到用戶的測試機器上驗證，發(fā)現(xiàn)客戶的服務器并沒有回滾，前2條數(shù)據(jù)入庫了；所以我們斷定客戶的環(huán)境出了問題。11.后面一天我們都在修改was服務的配置，以為是數(shù)據(jù)源配置錯了，導致數(shù)據(jù)庫連接不受事務管理；折騰了一天之后，最后發(fā)現(xiàn)was環(huán)境下，即使外部開了事務，Connection的autoCommit狀態(tài)就是true，不像tomcat，Connection受事務管理之后，autoCommit是false；12.根據(jù)日志，如果說Connection的autoCommit狀態(tài)是true是正確的，那么Connection的狀態(tài)是false則可能就會存在問題；因為正確日志和錯誤日志只有這個地方存在區(qū)別；所以這個時候我們懷疑是連接壞了；繼續(xù)分析日志，發(fā)現(xiàn)日志里面有在邏輯流里面調(diào)用了setAutoCommit的方法，用戶代碼將autoCommit屬性設置了false，所以我們?nèi)プ卟橛脩舸a，找到調(diào)用setAutoCommit的地方。四.解決問題1.找到用戶代碼之后，詢問當事人為什么需要將Connection設置成false，當事人也說不出正確的理由，而且還說這個可以去掉，他只是復制的；所以我們將這行代碼注釋好之后，部署到測試服務器驗證；同時驗證打補丁之前和打補丁之后的測試環(huán)境，此時，則是環(huán)境能重現(xiàn)問題了，然后打上補丁之后，問題未能重現(xiàn)。第二天將補丁打到生產(chǎn)環(huán)境，問題也未能重現(xiàn)，問題即解決。2.在問題的驗證過程中，有人提出，在was容器下，Connection的autoCommit狀態(tài)無論是true或者false對事務管理器沒有任何影響，因為通過走j2ee事務的標準接口，在was容器下，無論autoCommit的狀態(tài)是true還是false，事務管理器都是正常的；3.第二天我們對這一問題進行了驗證，發(fā)現(xiàn)在was環(huán)境下，通過j2ee事務的標準接口使用事務，Connection的autoCommit狀態(tài)true或者false，標準接口的事務確實不受影響；所以從另一個方面來說，eos的事務管理器對Connection的autoCommit狀態(tài)為false這種情況支持的不夠完善；五.結(jié)論1.從解決問題的角度，我們不建議用戶直接將Connection的autoCommit設置為false，理由就是這樣破壞了數(shù)據(jù)庫連接；如果用戶需要將連接設置為false，則需要在用完連接后，將連接的狀態(tài)設置回去；或者直接在外層使用事務。2.從產(chǎn)品的角度，由于標準接口true或者false2種情況都支持，所以也可以說是EOS的事務管理器支持的不完善，在特定的環(huán)境下，事務管理器應該支持這2種情況。EOS6中配置C3P0數(shù)據(jù)源自動重連方案文章

>

hanning

>

文章詳情EOS6中配置C3P0數(shù)據(jù)源自動重連方案

hanning

發(fā)表于9個月前

來自話題

#應用開發(fā)平臺（EOSPlatform）#

·

116

瀏覽【適用范圍】EOS6.0、Tomcat、Jboss、Oracle【問題描述和定位】在使用EOS6.0的時候，啟動了Server后，如果網(wǎng)絡出現(xiàn)問題Connectionreset異常，Oracle數(shù)據(jù)庫連接斷了后就不能進行操作了，需要重新啟動Server。那么，怎樣配置可以避免重啟Server，特別對于生產(chǎn)環(huán)境而言，需要盡可能的避免重啟?！窘鉀Q方案和步驟】1、Tomcat：在EOSGovernor控制臺的配置->數(shù)據(jù)源中，選中某數(shù)據(jù)源，點擊修改，將“連接重試次數(shù)”默認值-1修改為1，點擊“確定”保存。重啟Server。

或者直接修改目錄D:\primetonfor3207_platform\eosserver\working\eos-default\config下user-config.xml文件中DataSource的配置：

<configValuekey="Retry-Connect-Count">-1</configValue>修改為

<configValuekey="Retry-Connect-Count">1</configValue>2、JBoss：修改$JBOSS_HOME\server\default\deploy下的EOSProductDataSource-ds.xml，將默認的數(shù)據(jù)源配置改成如下（與EOS5環(huán)境下配置類似）：<local-tx-datasource><jndi-name>EOSDefaultDataSource</jndi-name><connection-url>jdbc:oracle:thin:@23:1521:pso</connection-url><driver-class>oracle.jdbc.driver.OracleDriver</driver-class><connection-propertyname="user">eos60</connection-property><connection-propertyname="password">eos60</connection-property><min-pool-size>5</min-pool-size><max-pool-size>100</max-pool-size><blocking-timeout-millis>5000</blocking-timeout-millis><idle-timeout-minutes>15</idle-timeout-minutes><valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name><check-valid-connection-sql>select1fromdual</check-valid-connection-sql><new-connection-sql>select1fromdual</new-connection-sql></local-tx-datasource>【備注】修改這個配置還可以解決如果系統(tǒng)中需要多數(shù)據(jù)源的話，在這個文件中增加一個local-tx-datasource配置；上面的配置可能對系統(tǒng)訪問數(shù)據(jù)庫的性能有影響，有可能每次拿數(shù)據(jù)庫連接的時候都會自動調(diào)用這個sql語句；Weblogic、Websphere等應用服務器也應該提供了類似的自動重連機制，可以進到它們的控制臺查看。EOS異常處理方法異常獲取EOS的異常獲取分為兩種，一種是在邏輯流中獲取異常，另一種是在java代碼中獲取異常。1.在邏輯流中獲取異常如上圖所示，開發(fā)人員需要在特定的圖元上通過添加異常線并添加異常拋出圖元（在