나중에 검색할 수 있도록 원래 요청 메시지의 ReplyToQ 및 ReplyToQmgr 값을 WebSphere MQ 메시지에 저장할 때, 단지 ReplyToQ 및 ReplyToQMgr 세부사항만 저장하는 대신 요청 메시지의 MQMD 전체가 저장됩니다. 이렇게 하는 이유는 세 값, 즉 ReplyToQ, ReplyToQmgr 및 CorrelID 값을 저장하고 검색할 필요가 있으며 MQGet 노드는 단일 값만 저장하거나 검색하도록 허용하기 때문입니다. 이러한 MQGet 노드의 작동 때문에, 개별 값 대신 필요한 값이 들어 있는 구조가 저장되어야 합니다. 서로 다른 값을 저장하도록 샘플을 변경할 경우, 이러한 MQGet 노드의 작동을 기억해 두어야 합니다.
Coordinated Request Reply 샘플은 이 샘플에 제공된 방법 대신 Request 및 Repy 플로우에 사용된 서브플로우의 여러 가지 구현을 사용할 수 있는 방법으로 설계되었습니다. 한 가지 다른 구현은 예를 들어 초기 요청 메시지의 ReplyToQ 및 ReplyToQmgr 저장영역에 데이터베이스를 사용하는 것일 수 있습니다. 이 방법은 성능을 향상시키기 위한 방법으로 바람직하지는 않습니다. 또는 요청 메시지의 ReplyToQ, ReplyToQmgr 및 CorrelID를 WebSphere MQ 메시지에 저장하고 검색하는 데 사용되는 서버플로우를 다른 메시지 플로우에서 사용할 수도 있습니다.
StoreOriginalMQMD_Sub 서브플로우는 다른 메시지 플로우에서 WebSphere MQ 메시지에 요청 메시지의 MQMD를 저장하는 것과 동일한 기능을 수행하는 데 쉽게 사용될 수 있습니다. 이를 수행하려면 이 서브플로우를 사용할 메시지 플로우의 적절한 위치에 서브플로우를 포함시키십시오. 서브플로우를 수정하지 않고 포함시킬 수도 있지만 다음과 같은 문제점이 나타날 수 있습니다.
변경될 필요가 있을 수 있는 주요 매개변수를 위에 나타냈기는 했지만 서브플로우에 있는 노드의 모든 매개변수 설정을 검토하여 사용자의 요구사항과 호환 가능한지 확인하는 것이 좋습니다.
데이터에 대체 저장영역 기능을 사용하기 위해 서브플로우를 수정할 수 있는 방법은 여러 가지가 있습니다. 예를 들어, 한 가지 대체 방법은 데이터베이스를 사용하는 것입니다. WebSphere MQ 메시지를 쓰는 대신 서브플로우는 데이터를 데이터베이스에 삽입해야 합니다.
저장영역 기능을 변경하면 서브플로우의 성능 특성이 변경됩니다. 사용자가 선택하는 구현의 특성이 메시지 플로우의 성능 요구사항과 일치하는지 확인해야 합니다. 정보를 보존하기 위해 데이터베이스를 사용하면 데이터베이스에 삽입될 때마다 데이터베이스 관리자 로그에 기록되어야 하므로 메시지 플로우가 처리 시 I/O 바운드가 될 가능성이 훨씬 더 높아집니다.
대체 저장영역 기능을 사용하면 서브플로우의 트랜잭션 등록 정보도 변경할 수 있습니다. WebSphere MQ 메시지를 사용하여 데이터를 저장할 때, 데이터는 메시지 플로우의 다른 곳에서 읽어들이는 WebSphere MQ 메시지와 동일한 자원 관리자를 사용합니다. 메시지 플로우에서 WebSphere MQ 메시지만을 처리하는 경우, 단일 자원 관리자만 관련됩니다. 데이터베이스 또는 기타 복구 가능한 자원 관리자를 사용하려면 데이터 무결성을 보장하기 위해 데이터가 저장되는 데이터베이스의 데이터베이스 관리자와 Message Broker 큐 관리자 사이에 2단계 확약 복구 프로토콜을 사용해야 합니다.
변경할 때는 서브플로우에 있는 노드의 모든 매개변수 설정을 검토하여 사용자의 요구사항과 호환 가능한지 확인하는 것이 좋습니다.
RestoreOriginalMQMD_Sub 서브플로우는 다른 메시지 플로우에서 WebSphere MQ 메시지로부터 초기 요청 메시지의 MQMD를 검색하는 동일한 기능을 수행하는 데 쉽게 사용될 수 있습니다. 이를 수행하려면 이 서브플로우를 사용할 메시지 플로우의 적절한 위치에 서브플로우를 포함시키십시오. 서브플로우를 수정하지 않고 포함시킬 수도 있지만 다음과 같은 문제점이 나타날 수 있습니다.
변경될 필요가 있을 수 있는 주요 매개변수를 위에 나타냈기는 했지만 서브플로우에 있는 노드의 모든 매개변수 설정을 검토하여 사용자의 요구사항과 호환 가능한지 확인하는 것이 좋습니다.
데이터에 대체 저장영역 기능을 사용하기 위해 서브플로우를 수정할 수 있는 방법은 여러 가지가 있습니다. 예를 들어, 데이터베이스를 사용할 수도 있습니다. WebSphere MQ 메시지를 읽기 위해 MQGet 노드를 사용하는 대신 서브플로우는 데이터베이스에서 데이터를 읽을 수 있습니다.
저장영역 기능을 변경하면 서브플로우의 성능 특성이 변경됩니다. 사용자가 선택하는 구현의 특성이 메시지 플로우의 성능 요구사항과 일치하는지 확인해야 합니다. 정보를 보존하기 위해 데이터베이스를 사용할 때 구현에 따라 서로 다르게 오버헤드를 추가할 수 있습니다. 읽기를 사용하여 데이터를 검색하고 갱신하거나 삭제하지 않으면, 오버헤드는 데이터베이스 구현에서 최저 상태가 됩니다. 그러나 데이터베이스에서 데이터를 삭제하지 않으면 데이터베이스 크기가 계속 증가되어 정리 조치를 취하지 않을 경우 사용 속도가 점차 느려지게 됩니다. 검색 프로세스가 데이터가 검색되었음을 표시하기 위해 행의 갱신이나 삭제를 포함할 경우, 데이터베이스 관리자 로그에 대한 쓰기를 포함하므로, 읽기 전용의 경우보다 상당히 큰 처리 오버헤드를 수반하게 됩니다.
대체 저장영역 기능을 사용하면 서브플로우의 트랜잭션 등록 정보도 변경할 수 있습니다. WebSphere MQ 메시지를 사용하여 데이터를 저장할 때, 데이터는 메시지 플로우의 다른 곳에서 읽어들이는 WebSphere MQ 메시지와 동일한 자원 관리자를 사용합니다. 메시지 플로우에서 WebSphere MQ 메시지만을 처리하는 경우, 단일 자원 관리자만 관련됩니다. 데이터베이스 또는 기타 복구 가능한 자원 관리자를 사용하려면 데이터 무결성을 보장하기 위해 데이터가 저장되는 데이터베이스의 데이터베이스 관리자와 Message Broker 큐 관리자 사이에 2단계 확약 복구 프로토콜을 사용해야 합니다.
변경할 때는 서브플로우에 있는 노드의 모든 매개변수 설정을 검토하여 사용자의 요구사항과 호환 가능한지 확인하는 것이 좋습니다.