relocMode 관련 정리/중복노드실행/하나의 AP만 호출되는 경우

nwa > configuration > java system properties > service > xpi service: af core > scheduler의 relocMode에 대해

relocMode는 예를들어 3으로 설정 시 각 채널의 1개의 서버노드에서 3회 폴링 후 다른 노드에서 폴링

1로 설정 시 JDBC채널 개수가 많고 폴링 간격이 짧은경우 성능이 저하

-5로 설정된 경우 매 5번째 폴링마다 CPACache서비스의 값에 대한 URL를 검색하여 호출

중복노드 실행관련 되서

짧은 폴링주기로 실행되는 몇개의 채널에서 확인되는 노드 중복실행 현상

예를들어 JDBC어댑터인경우 clusterSyncMode의 'Scheduler' 설정으로 해결이 가능할것 같다.

SAP Note 801367 - XI 3.0 JDBC Adapter: Additional Parameters 참고

L4의 로드밸런서에서 하나의 AP나 노드만 호출되는 현상

2462752 - The sender polling channels do not take the load balance in cluster nodes의 

/AdapterFramework/scheduler/scheduler.jsp?xml를 통한 실행안되는 노드를 찾을수 있는것 같음

잡 디스패처 URL를 통한 로드 밸런싱되는 AP,노드 확인

http://<로드밸런서>:50000/AdapterFramework/util/servlet/DeliveryServlet?target=ejb:localejbs/AF/JobDispatcherBean

관련 값은 XPI Service: CPA Cache > selfregistration통해 확인

이전 작성한 관련 글입니다.

scheduler.relocMode 값이 샌더채널의 폴링실행시 주는 현상

SAP PO의 MaxThreadCount,Message Queue,maxReceivers 스레드에 대한 이해정리

지금까지 스레드나 병렬처리 등에 대한 내용도 찾아보고 경험도 해보았는데 전부는 아니지만 이해한것 까지만 정리를 해보았는데요. MaxThreadCount,Queue Threads, maxReceivers 설정 값과 PI Receiver Parallelism 기능을 알면 SAP PO내에 메시지처리에 정체현상이 있는경우 이해하고 대응할수 있을것 같습니다.

운영 상 PO의 AP서버들이 4개(Instances)고 인스턴스의 각 서버노드별 아이디(Process)가 9개이며 REST어댑터의 큐에서 처리할수 있는 스레드 개수가 30개(메시지 큐마다 다름)로 구성이 되어있다고 한다면?

이때 서버 별 병렬처리될때 생성 가능한스레드 개수는 270개, AP서버가 총 4대니 여러서버에서 동시에 REST 방식의 큐는 1,080개의 메시지를 처리할수 있는 구성이라고 이해 됩니다.(L4같은 로드밸런싱 처리에 따라 다를수 있을것 같음)

그리고 MaxThreadCount는 서버내 동시처리할수 있는 최대 스레드 값을 지정할수 있다고 하는데 각 메시지 큐의 스레드를 지정하는 스레드 설정과 다르게 일반적으로 MaxThreadsCount는 메시지 큐스레드보다 높게 설정한다고 하지만 이부분은 정확한 가이드를 받아 해당 서버의 최적의 조건을 찾아야될것 같습니다.

SAP PO 표준 메시지 사이즈에 대한 정리

PI 7.1 아니면 그 이전부터 메시지 표준사이즈를 1~5MB로 오래전부터 가이드를 했던것 같은데 XI/PI/PO 로 버젼이 업그레이드 되면서 표준 메시지 사이즈에 대해서도 변화가 있지 않을까 생각되어 관련 내용을 찾아보았습니다.

2012년도의 'PI 7.3 Benchmarks for message size and throughpu' 라는 페이지의 글을 보면 

PI의 최대 1GB파일을 처리(하드웨어,매핑 등 에 따라 달라질수 있음)할수 있지만 1~5MB가 권장하는 사이즈라고 하는데  7.31로 업그레이드 이후에 큰 메시지에서 처리속도가 느려져서 다시 1~5MB로 시도를 했다고 보이는군요.

그리고 예전 듀얼스텍보다 AAE버전이 메시지 처리속도가 더 빠르다고 하는데 이부분은 인정할수 밖에 없는게 기존 ABAP스텍+JAVA스텍이 환경에서 싱글 JAVA스텍을 사용하니 겉보기에도 빨라보일것 같습니다.

"PO를 사용하다 보면 PO부하로 인해 최적의사이즈로 가이드 하는줄 아는 사람도 본것 같은데 맞긴하지만 거기에 PO와 연계시스템들까지 포함되어 인터페이스 성능에 영향이 있다고 이해해주면 좋을것 같군요"

2013년도에 작성된 'SAP PI 7.1 Tips and Tricks' 글을 보면

PI 7.1에서의 튜닝 후 처리량 관련 테스트를 진행했을때 성능개선 및 메모리 오버플로를 방지하여 안전성 높이는 평균 메시지 크기로 1MB에서 5MB범위로 유지하는걸로 보이는군요.

SAP PO인시던트 등록할때 필요한 분석,디버깅,덤프 등 관련 노츠

SAP PO에서 발생되는 문제들에 대한 빠른해결 방법으로 인시던트를 등록 후 지원받는 방법이 있는데 이 방법은 인시던트 등록할때 문제가 발생될때 로그나 덤프파일 등을 같이 첨부해주면 조금더 빠른 지원을 받을수 있는것 같습니다.

이런 빠른 지원을 받을수 있는 가장 기본적인 건 아마도 엑셀에 해당 문제나 에러에 대한 스크린샷을 붙여놓는것 같습니다.

1095473 - How to get a full thread dump in AS Java

SAP NetWeaver내의 서버(PO포함) 내에 자바 스레드 덤프를 가져올수 있는 사용방법 링크가 들어있는데 이 사이트만 봐도 되겠네요.

(JSTTSG) (Deploy) Thread Dump

1847251 - How to create and load an SAP MC snapshost: SAP AS JAVA

SAP MMC(Management Console)의 서버의 스냅샵 생성방법에 대해 볼수 있습니다.

1757810 - How to get the complete list of software components on your NewWeaver Application Server Java

NeWeaver 자바스텍에 설치된 소프트웨어 컴포넌트 목록과 버젼에 대해 확인 할수 있습니다.

1995883 - Analyzing slow AS-JAVA startup using the SAPJVM Profiler

성능문제 발생 시 해결을 위한 분석 툴입니다.

1514898 - XPI Inspector for troubleshooting XI

애플리케이션 서버 내에서 사용하면서 발생되는 문제에 대한 원인을 찾기위한 툴 내용에 대해 볼수 있습니다.

위의 노츠들은 인시던트 등록 후 SAP 지원팀에서 요청하는 자료에 대한 요청내용에 포함되어있는 Note들입니다.

이전에 작성한 관련 글은

SAP 인시던트 등록하는 방법

Adapter Framework 동기 폴링채널 흐름

로드 밸런서(L4)에서의 노드 배포를 위한 잡 디스패처(XPI Service: CPA Cache)

• scheduler.relocMode값에 따른 노드 재배치(XPI Service: AF Core)

특정 PO AP서버의 노드에서 폴링

• CPA Cache에서 채널정보 가져오거나 업데이트

CallSapAdapter가 실행 후 관련 여러 스레드들(AFScheduler,Worker 등) 확인

• *synchronized Map에 저장
• lock 생성
• MMC,Channel Monitoring에서 확인 가능

Message Queue(Dispatcher queue)

• 메시지의 여러상태와 로그, 데이터들을 확인 가능
• Message Monitoring에서 확인가능

타겟시스템에 대한 수신정보 설정 후 전송

• 스레드가 실행되어 타겟에 전송(SystemCall,SystemSend 등)
• Sender서비스 종료 후 unlock처리
• 다음폴링 가능한 상태로 전환

*synchronized Map: 샌더채널 실행 시 해당 MAP에 저장하며 실행중인 서비스에 문제가 있는경우 MAP 락을 걸어 다음 채널 등록을 방지

이전에 작성한 관련글은

scheduler.relocMode 값이 샌더채널의 폴링실행시 주는 현상

PO의 EJB Session에 대한 정리

NWA > Resource Monitoring > History Reports > Monitor Browser메뉴의 'Opened EJB Sessions Count' 검색을 통해 SAP PO내의 EJB Session 상태를 알수 있는것 같고 해당 세션이 PO내에 어떤 영향으로 발생되는지에 대해 알수 있는 내용에 대해 정리를 했습니다.

EJB세션의 특징과 이점

• EJB(Enterprise JavaBeans)
• 분산 환경에서 실행되는 애플리케이션
• SAP PO 자바스택의 구성에 해당 
• PO내의 EJB컨테이너에서 실행
• EJB컨테이너는 컴포넌트(비즈니스로직 처리)를 실행하는 환경
• EJB세션은 클라이언트와 서버간의 통신을 위한 객체
• EJB컴포넌트를 배치하는 방법으로 NWDS툴을 사용한 개발이 있음(모듈 → 세션 빈 → 메서드 추가 후 디폴로이)

그외 EJB세션이 사용되는 컴포넌트들로 AE(Adapter Engine),MM(Message Mapping)가 있고 그외 싱글스텍에서 사용 안하는 용어로 IE(Integration Engine),Receiver Determination과 Interface Determination이 있으며 그중 AE의 기능으로  PO서버와 외부시스템간의 통신하여 메시지를 변환,전송,수신,검증,보안 등을 처리한다고 합니다.

EJB세션의 구성

http://<host>:<port>/ejbexplorer에서 EJB세션 빈 구성에 대해 볼수 있으며 관련 PO내 기술로는 JavaProxy,AdapterModule 등이 존재하며

자바프록시: Application > Module > Stateless Session Bean

어댑터모듈: Application > Module > Stateless Session Bean > Local Business Interface,Component Interface,Home Interface > Business Method

일반적으로 위와 같이 구성되는것 같습니다.

이전에 작성한 관련 글입니다.

What is EJB Session in SAP PO Management Console?

Receiver REST어댑터 네임스페이스 매핑 사용방법

JSON데이터 안에 urn:test:1.0:User로 되어있는 네임페이스를 XML로 매핑 변환하거나 반대로 XML → JSON으로 REST 어댑터 안에 옵션을 통해 변환할수 있는 방법에 대해 정리하였습니다.

실제로 사용해보진 않았지만 관련 사이트 내용들을 보면 이런 데이터에 대해 일반적으로 처리가 가능해 보입니다.

XML/JSON 네임스페이스 매핑 옵션은 REST Receiver 어댑터 > Data Format > Convert XML Payload to JSON 체크 > Enable Namespace Mapping 체크를 하면 보이는데 네임스페이스,배열,데이터타입 등에 대해 자동변환은 지원은 안되는걸로 확인이 됩니다.

해당 옵션을 사용하기 전에 

SimpleTools의 JSON/XML 변환기를 통해 JSON과 XML 간 변화되는 데이터

를 미리 보시는것도 도움이 되실것 같습니다.

 

하나 예를 들어

여러 데이터 타입과 네임스페이스를 포함한 아래의 JSON데이터를 

{

 "root": [

  "urn:test:params:test:schemas:core:1.0:User",

  {"number" : 2023},

  {"string" : "aaa"},

  {"boolean" : false},

  {"object" : {"AAA":"aaa","BBB":"bbb","CCC":"ccc"}},

  {"array" : ["aa","bb","cc"]},

  {"null" : null}

 ],

 "string1" : "bbb",

 "urn:test:params:test:schemas:extension:1.0:User":{

  "number1" : "0329",

  "boolean1" : true

 }

}

JDBC Receiver 어댑터 바인딩모드 사용 시 에러정리(오라클)

SAP PO에서 타겟쪽 JDBC어댑터에서 기본설정으로 사용 시 리터널 쿼리로 실행이 되며 가끔 DBA한테 해당 쿼리에 대해 바인딩 처리해달라는 요청이 오는경우가 있습니다. 

이런경우 오라클인경우 'alter session set cursor_sharing' 처리를 하거나 채널의 옵션을 사용해 바인딩처리를 하는데 리터널 쿼리의 기본적인 사용법보다 제약사항도 있고 컬럼 타입별로 사용방법도 번거로운부분이 존재하 기도 하지만 처리속도는 향상되는것 같습니다.

해당 내용은 바인딩 사용 시 발생되는 에러와 원인 등에 대해 정리한 글입니다.

기본 바인딩 구성

• 타겟 DB 컬럼타입에 NUMBER, DATE 타입존재
• 타겟 Insert DataType의 어커런스는 Statement는 0..1, access는 0..n
• Receiver Adapter > Advanced 설정
• Batch Mode는 체크
• sqlBindMode는 true
• dataWithBindMode는 true

바인딩 사용 시 에러 정리

에러내용은 

java.sql.SQLException: FATAL ERROR in structure 'Statement': SQL queries are not supported in SQL Bind mode

생성된 구조에 오류가 있고 SQL 바인드 모드에서는 SQL쿼리가 지원되지 않습니다.

SAP PO 메시징 시스템 병렬처리 제한 파라메터 사용방법

SAP PO 메시징 시스템 내부의 인터페이스 작업스레드의 처리가 정체 되거나 개선이 필요한 경우 사용되는 파라메터나 기능들에 대해 정리를 하였습니다.

Maximum Concurrency

채널이 데이터 베이스에 허용하는 병렬 연결 수라고 하며 병렬로 처리할수 있는 허용 스레드 수보다 낮아서는 안된다고 이해를 하는데 어느 스레드의 수치값을 이야기하는건지는 모르겠습니다.(같이 이해 하면 좋을것 같은 'poolWaitingTime')

messaging.connectionDefinition

스레드 수는 NWA > JavaSystem Properties > XPI Service: AF Core나 Adapter Engine Status > Additional Data에서 확인이 가능합니다.(서로 내용이 다른경우가 있는것 같음)

• 어댑터의 채널에서 사용할수 있는 총 스레드 수
• 메시지의 To-Be Delivered 상태, 정체 등 발생시 해당 어댑터 스레드 수를 늘려 해결하는 경우가 있음

1623356 - "To be delivered" messages in Adapter Engine 참고

SAP PO JDBC Adapter의 'Disconnect from Database After Processing Each Message' 옵션에 대해

어느 answers.sap.com 사이트의 글에서 

Sender,Receiver JDBC Adapter > Advanced의 'Disconnect from Database After Processing Each Message' 옵션에 대한 용도와 어떠한 현상에서 체크를 해야하는지에 대한 문의를 남긴 글을 보았었습니다.

저도 SAP PO 작업을 하면서 신규 같은경우 HTTP,SOAP 등의 연계방식을 통한 실시간,배치로 수행되는 인터페이스들만 보다 최근 몇년 사이에 다른 EAI 솔루션에서 PO로 많은 DB연계방식의 인터페이스들을 전환할때 이 옵션을 필수로 체크하는 경우를 보았고 대략 어느 기능을 하는지는 알지만 다시한번 간략하게 정리를 해보려고합니다.

해당 문의에 대해 어떤 사람은 아래와 같이 답변을 남긴 글을 재정리해보면

이 옵션이 체크되어있는 경우 Sender어댑터는 각 폴링 마다 DB연결을 해제 후 다시 연결을 시도하며 폴링 주기가 짧은 경우 항상 열결이 되게 하는게 좋습니다. 하지만 Receiver어댑터 같은경우 소스쪽 연계방식과 호출주기에 따라 다를것 같은데 전송되는 메시지 주기가 큰 경우 해당 옵션을 사용하는게 DB부하를 줄이데 도움을 줄 수 있습니다.

2633269 - Processing delay in PI JDBC Receiver message 참고

이 노츠의 일부분을 보면

"이 연결해제 옵션을 사용하면 DB수준에서 연결을 해제하는데 문제가 있는 경우 도움이 될수 있습니다.(단, 이 옵션을 사용하면 부하가 많은 상황에서 처리 시간이 느려질수 있습니다)"

정리한 내용을 요약하면 

호출 빈도(몇초?)가 짧은 메시지를 전송하는 인터페이스인경우 해당 옵션을 사용안하는게 좋은것 같고 네트워크오류나 빈도가 긴 인터페이스들은 이 옵션을 사용하는게 연계하는 시스템이나 DB에 부하를 줄일수(얼마나?) 있는것 같습니다. 

DB연계방식의 인터페이스에서 발생되는 여러 에러들에 해결방법으로 연결해제 옵션 외에도  'Maximum Concurrency' 값 조정 등 여러 해결방법의 내용들을 볼수 있었습니다. 

SAP PO에서의 ORA-00933: SQL 명령어가 올바르게 종료되지 않았습니다 에러원인

SAP PO의 JDBC Receiver어댑터 연계한 인터페이스에서 발생되었던 오라클에러인 'ORA-00933: SQL 명령어가 올바르게 종료되지 않습니다(SQL command not properly ended' 에러에 대한 원인에 대해 정리를 하였습니다.

에러내용을 보고 잘 몰라 구글에 검색을하게 되면 일반적으로 구문,문법 오류 작성한 쿼리에 대한 오타 등 내용들을 볼수 있지만 

구문오류가 아닌

소스쪽에서 보내는 데이터와 타겟DB 테이블의 컬럼타입간에 오류였습니다.

에러로그의 페이로드나 Receiver어댑터의 logSQLStatement 파라메터를 셋팅하고 실행되는 쿼리를 보고는 알수는 없었지만 정상적으로 처리되는 데이터와 실패되는 데이터를 비교해보면 특정컬럼의 데이터가 다른경우를 볼수 있고 

이번 에러의 원인은 예를 들어 특정 컬럼의 데이터가 2311addf일때는 에러가 발생되고 2311일때 성공되었습니다.

SAP PO의 오라클 연계 인터페이스를 보면 에러내용이 직관적이라서 다른 DB(MS-SQL,MY-SQL,DB2 등)들보다 에러원인을 찾는데 수월하지만 이번에러같은경우는 좀 햇갈렸던것 같습니다.

SAP JVM Profiler 사용방법 및 메뉴정리

SAP PO의 JVM Profiler의 화면에 대해서 간략하게 정리를 하였는데 일반적으로 BC쪽에서 보는 화면같고 PO담당자가 보는 화면은 아닌것 같습니다.

NWDS의 SAP JVM Profiler 설치는 아래 내용을 참고

2621050 - How to profile and analyze AS JAVA performance using SAP JVM Eclipse plug-in

Manage Hosts에 PO정보 :1099를 추가하게 되면 VM Explorer에 각 JVM(노드별)정보가 나오며 아래 옵션의 항목에 지정된 값에 따라 분석결과(Snapshot)를 볼수 있는것 같습니다.

Analysis Options

User, Session, Request, Application, Tenant, Class

각 분석메뉴마다 실행된 결과를 볼수 있는데 PO모니터터링 화면에서 볼수 없는 클래스,메서드,메모리 등의 성능적인 부분도 확인할수 있는것 같고 대부분 커스텀으로 개발된 PO환경인경우 해당메뉴는 필수적으로 체크를 해봐야되는 부분일것 같습니다(개인적인 생각)

SAP PO에서의 MySQL,MariaDB 문법에러(백슬래시)

에러내용

"java.sql.SQLSyntaxErrorException: you have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near..."

원인

데이터 문제인지는 예상했지만 데이터에 'TEST.￦' 이렇게 들어가 있을때 에러가 발생되었는데 ￦를 제거하고 전송하면 성공되며 자바에서의 백슬래시나 따옴표 등 문자에서는 별도의 처리(이스케이프시퀀스)가 필요하다고 하는데요.

￦' 이렇게 데이터가 들어갈때 '로 출력이 될텐데 왜 에러나는건지 모르겠습니다.

그외 관련 글입니다.

SAP PO에서 UTF8MB4 데이터처리를 어떻게 해야할까요?

SAP PO 동기 Timeout 파라메터 asyncMessageDeliveryTimeoutMsec,syncTimeout,xiadapter.inbound.timeout.default

PO 내부와 채널에서는 여러 타임아웃 파라메터가 설정되어있으며 인터페이스 수행 중 설정된 시간보다 초과가 되면 타임아웃 에러가 발생되는 경우가 있는데 이런 에러와 관련된 파라메터에 대해 알아보려고 합니다.

How To... Investigate Timeouts InSynchronous XI/PI Scenarios.pdf 참고

Java Service Properties for the Adapter Framework 참고

syncMessageDeliveryTimeoutMsec

NWA > Java System Properties: Overview > Services에

XPI Adapter: BC와 XPI Adapter: RFC에서 볼수 있는 파라메터이며 다른 어댑터에도 영향있는 부분인지는 모르겠지만 RFC 샌더채널 연계방식으로 동기 메시지를 전송 후에 파라메터(syncMessageDeliveryTimeoutMsec)에 지정된 시간이 경과된 경우 타임아웃 예외처리가 발생되는것으로 보입니다.

*관련용어: AdapterFramework, Module processor, RfcAFBean,

sRFC(BE:Best Effort), tRFC(EO:Exactly Once)

SAPXIPP와 Principal Propagation은 무엇인가?

SAP GUI기능에서 SAPXIPP100와 Principal Propagation으로 인한 현상에 대해 지인분 통해 듣게된 내용을 기억을 더듬어 보며 정리해보려고 합니다.

SAPXIPP100 Destination 정보가 없어 SXI_MONITOR에서 재처리 안되거나 SXMB_ADM > Configure Principal Propagation 실행 시  오류 등이 보이는경우가 있는것 같습니다.

PP(Principal Propagation)이란?

Configuration of Principal Propagation 참고

메시지인증관련 기능같은데.. 사용자 컨텍스트를 발신자에게 수신자로 변경하지 않고? 전송하는 기능이라고 하고 송신측의 유저로 수신 시스템 내에 인증이 가능하게 해준다고 보이는데 뭔가 SSO(Single Sign-On)와도 비슷한 기능인것 같기도 합니다.

PP는 SAP assertion tickets통해 인증을 사용한다는데 XI(ABAP,JAVA프록시),SOAP,RFC,WS(SAML) 에서도 지원이 된다고 하고  IS(Integration Server),IE(Integration Engine)에서 해당 기능을 사용하려면 SAP시스템의 특정권한이 존재하는 PIPUSER유저의 SAPXIPP 컨넥션 생성이 필요한걸로 보입니다.

캐시에러 Lookup single item of ConfigurationScope not possible...

JDBC어댑터를 수정 후에 샌더채널이 실행되거나 인터페이스 수행이 될때 타겟채널에서 아래와 같은 에러가 확인이 될때가 있는데 해당 채널의 ICO(Integrated Configuration)를 다시 저장후에 정상 작동하는것을 확인하였습니다.

 

java.lang.RuntimeException: Lookup single item of ConfigurationScope not possible, because CPA returned more than one single item. Duplicated entries in CPA cache for partial key: [ICO

에러 메시지나 2886793 - Dulicated entries in CPA Cache 내용을 보면 해당 오브젝트 키로 CPA캐시에 중복된 엔트리가 존재? 한다고 하는데 채널을 수정 후에 CPA Cache History: Overview에서는 정상으로 보이지만 NWA > Adapter Engine > Cache Monitor에서 해당 오브젝트 아이디로 조회 시 채널수정된 화면과 다르게 확인이 되며 

예를들어 타겟채널인 경우 Receivers,Receiver Interfaces,Outbound Processing 항목에 중복된 부분이 확인되는 경우가 있습니다.

이런 현상들이 발생되는 원인은 아직은 모르겠지만 근본적인 원인을 찾아야 필요가 있는것 같습니다.

이전에 정리한 캐시관련 글입니다.

SAP PO 캐시 특징,순서

SAP PO에서의 ORA-00904 부적합한 식별자 에러

SAP PO에서 JDBC어댑터를 통한 오라클 DB연계 후 발생 되는 인터페이스 에러들을 보면 대부분 에러메시지를 보면 원인을 바로 알수 있는데 

이번에 보았던 ORA-00904 "BB": 부적합한 식별자(invalid identifier)대한 에러의 원인이 달랐던것 같습니다.

일반적으로 테이블이나 컬럼이 없을때 발생되는 에러인줄 알았지만 아래와 같이 컬럼 타입이 NUMBER일때 문자데이터가 들어간경우 발생되는것 같습니다.

JDBC XML구조 

<key>

 <AAA>A-BB-123456</AAA>

</key>

SAP_AFScheduler.Worker 콜스텍 java.net.SocketInputStream.socketRead 행 현상

오라클DB와 연계되어 있는 JDBC Sender채널 하나가 SAP MMC(Management Console)의 Call Stack에서 장시간 스레드가 'RUNNABLE' 상태라 확인을 해보는 과정을 정리하였습니다.

실행중인 SAP_AFScheduler.Worker의 내용을 보면 마지막 실행된 프로그램이 java.net.SocketInputStream.socketRead까지이며 해당 스레드와 채널의 상태가 행(hanging)으로 보입니다.

왜 발생되고 어떻게 방지할수 있을까?

참고한 사이트의 웹로직의 내용을 보면 JDBC 컨넥션 풀이 구성된 데이터베이스가 어떠한 영향으로 SQL실행 결과에 대해 장시간 행(응답을못한 상태)현상이 보이는것이라 보이는데 이에 대한 확인방법으로는 해당 DB의 로그확인을 통한 상태확인인이 필요하다고 합니다.

또 다른 사이트를 보면 자바,스프링 기준으로 아래 타임아웃 설정을 해도

setConnectionRequestTimeout(3000)

setConnectTimeout(3000)

setReadTimeout(3000)

행 현상이 해결이 안되는지 JDK에 버그가 있다고 하며 업그레이드가 필요하다고 보입니다.

현재는 해당 현상의 발생 빈도가 적어서 신경쓰이는 문제는 아니지만 많이 진다면 타임아웃이나 다른 방법을 찾아 적용을 해보는게 좋을것 같습니다.

그 이후에 발생된 현상들을 정리해보면

똑같이 아래와 같은 콜스텍 내용을 볼수 있으며 메시지모니터링에서는 해당 메시지가 계속 Delivering 상태로 보입니다.

Thread 'SAP_AFScheduler.Worker'

java.lang.Thread.State: RUNNABLE

java.net.SocketInputStream.socketRead0

몇시간 후 채널의 행 현상 사라지고

채널에러는 

java.sq.SQLRecoverableException: No more data to read from socket

메시지로그는 정상, 특이점은 메시지 수행 정상로그가 09시인데 채널에러는 12시로 확인되었던적이 있습니다.

이전에 정리한 SAP_AFScheduler.Worker 관련글입니다.

scheduler.relocMode 값이 샌더채널의 폴링실행시 주는 현상

SAP PO 인증서 사전에 만료일 확인하는 웹서비스(KeystoreServiceApi)

외부시스템과 인터페이스를 하는 경우 PO나 타 시스템 인증서 등록이 필수로 적용이 되는경우가 있으며 매년 인증서 만료일에 대해 체크해봐야하는 작업이 있을수도 있는것 같습니다. 

PO내부에 등록된 인증서에 대한 만료일을 사전에 확인하는 방법에 대해 여러 사이트의 검색을 통한 내용을 정리해보았습니다.

인증서를 확인하는 방법으로는 NWA > Configuration > Security > Certificates and Keys 메뉴 등을 통해 인증서를 하나씩 눌러서 만료일을 확인하거나 만료일이 지나면 관련 인터페이스가 에러가 발생될텐데 이런 방법말고 좀더 자동화 할수 있는 방법에 대해 알아보려고합니다.

"가장 먼저 찾은 내용은"

SAP GUI로 접속하는 SAP시스템에서 인증서 만료일을 확인하는 내용입니다.

How to know expired SAP certificates 내용 참고

티코드 'SA38' 실행 후 'SSF_ALERT_CERTEXPIRE' 입력 후 실행하면 각 인증서의 만료일을 확인 가능합니다.

JWT(Json Web Token)는 무엇인가요?

지인한테 JWT에 대한 웹토큰방식? 에 대해 들어 궁금하여 간략하게 특징정리와 나중에 시간이 되면 기존에 알고 있었던 엑세스 토큰(OAuth 2.0) 방식과의 차이점을 비교해보는 내용도 정리해보려고 합니다.

JWT의 특징

• Json 포맷을 사용한 Claim기반의 웹 토큰
• 사용자 인증을 위한 오픈스텐다드(RFC 7519)
• 토큰 자체를 Self-Contained 방식으로 안전하게 전달
• 사용자 인증에 자주 사용
• 사용자 인증에 필요한 정보를 토큰 자체에 담고 있습니다(서버에 토큰정보를 저장할 필요없음)
• 일반토큰 기반과 다르게 별도의 인증저장소나 서버, 데이터베이스에 의존하지 않는다고 합니다
• JWT는 점으로 구분된 3개의 base64인코딩 문자열로 구성(header,payload,signature)
• 헤더는 암호화 알고리즘(SHA256,RSA 등),토큰등에 대한 정보
• 페이로드는 전달하려는 유저의정보(클레임),토큰에 대한 발급,만료일 등
• 서명은 Secret key로 암호화 후 토큰을 변조하기 어렵게 합니다(핵심적인) 
• C,JAVA,Python 등 여러 프로그래밍 언어에 지원
• 기존 세션 토큰의 분산화된 세션관리 문제 에 대한 보완
• 쿠키사용으로 인한 보안 취약점 개선
• 토큰이 노출되면 보안적으로 취약해질수 있습니다(로컬스토리지 저장 주의)
• 하나의 키에만 의존(키관리 중요)

*클레임이란? 사용자의 아이디나 기타 데이터들

*Self-contained란? 토큰 자체에 사용자의 권한,서비스 정보를 포함하는것