• 프로젝트 생성 버튼 클릭 시 다이얼로그 호출
• 다이얼로그에 프로젝트 명 입력 기능 추가하기
• 확인 버튼 클릭 시, 프로젝트 생성 API를 호출하기
  • 생성에 실패한 경우, 경고 알림 메시지 출력
  • 생성에 성공한 경우, 새로운 프로젝트 페이지를 만들기

Descrption

현재 프로젝트는 클라이언트에서 orthanc 서버를 접속하기 위해서 spring boot를 경유하는 로직을 갖추고 있다. 그러나 앞으로 추가될 orthanc 관련 API 코드 작성에 시간이 매우 소요되고 클라이언트 뷰에서의 접근 한계가 우려되므로 Nginx를 이용하여 리버스 프록시 설정을 시도하고자 한다.

Expected Problem

리버스 프록시를 사용하여 orthanc에 접근할 때, 보안 취약점이 발생할 수 있다.

Reference

1. https://jjeongil.tistory.com/1490
2. https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
3. https://gonna-be.tistory.com/20
4. https://bum752.github.io/posts/Docker%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%B4-%EC%9B%B9-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EA%B3%BC-NGINX-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-(with-docker-compose)/

스프링 코드 작성하고 돌려보려니까 Spring boot 실행이 안되네...
dependency 문제인 것 같은데, 뭐가 문제일까?
@BEOKS

orthanc는 Dicom 파일을 저장하기 때문에, 현재 프로젝트에서 가장 높은 보안 레벨이 적용되어야 한다. 어떤 방법이 있을까?

1. Spring Boot 로그인 정보를 바탕으로 orthanc 접속을 허락하기
   • 현재 클라이언트에서 nginx를 통해서 orthanc로 접속하는데 Spring boot로그인 정보를 바탕으로 nginx에서 보안을 설정 할 수 있을까?
   • Spring Boot에서 Zuul을 이용해서 nginx의 리버스 프록시처럼 설정할 수 있다고 하는데, 이를 이용하면 spring boot의 로그인 정보를 가져오는게 쉽지 않을까?
2. Orthanc에서 Securiting 관련 Docs가 있는데 이를 적용하는건 어떨까?(https://book.orthanc-server.com/faq/security.html)

Reference

1. https://book.orthanc-server.com/faq/security.html

problem :

기본적으로 Mongo를 사용할 시 application.yml 내에서 mongoDB에 대한 접근 방법을 정의할 수 있다.
Embedded MongoDB 역시 이를 참조 하여 접근하는 형식 인 듯하다. (물론 in memory Database에 대한 접근)
현재 application.yml 상태로 테스트 코드 진행 시 계속 authentication 에 대한 에러가 발생한다. 아마 Embedded MongoDB에 대한 접근권한 ( username, password) 와 같은 configuration 설정을 따로 해 줄 필요가 있을 듯한데.. 어떻게 해야할 지 잘 모르겠다.
임시방편으로는 TestCode실행시 application.yml 내 접근권한 ( username, password) 을 주석 처리해 주면 Testing이 가능하다.

proposal :

...

associated Task :

#38

https://www.notion.so/ListView-275b38f608c14b92bb3d841130aee465

https://www.notion.so/DicomWithCSV-API-6526bd15c89f46a5988661b754204f2e

Spring으로 서버를 전환한 후 기존에 구현되어 있던 아래의 미들웨어 기능의 Migration을 진행한다.

현재 미들웨어 기능

1. MongoDB와 연결
2. Dicom 메타 데이터 정보를 반환하는 API 구현

PatientID에 할당된 Study ID list를 json형식으로 반환하는 API생성

컴포넌트를 넣기 위한 전체적인 틀 제작 (타이틀 및 사이드 바 포함)

문제점:

기존의 다운로드 구현이 redirect하는 방식으로 구현이 되어있는데,

테스트시에는 localhost로 통신하므로 redirect가 잘되었는데
host를 orthanc로 설정 시 redirect가 되지 않는 문제가 있음

이유:

현재 orthanc는 스프링만을 통신이 가능한데,

redirect시, 웹브라우저에서 페이지가 넘어가면서 API가 호출되는 방식임
웹브라우저는 orthanc주소로 접근이 불가능하므로 다운로드가 받아지지 않는 문제가 있음

문제 상황

Epic: #75
Task: #73

Projects 데이터를 API에 요청해 받아오는 코드 작성 후, 이를 테스트해보려고 함.
테스트를 위해 아래의 절차를 따름.

1. API 사용을 위해 git cherry-pick으로 #70 의 commit(173cc7a, 9800360)을 가져온다.
2. run_docker.sh local로 컨테이너를 실행한다.
3. #78 를 참고하여 MongoDB Compass로 프로젝트 데이터를 생성한다.
4. yarn start로 클라이언트를 실행한다.

하지만 프록시가 동작하지 않아 404 Not Found Error가 발생했다.

해결하기 위해 시도해본 것

• yarn add http-proxy-middleware

• yarn install

• npm install

• http-proxy-middleware v1.0 이전 버전으로 setupProxy.js 코드 변경

const proxy = require('http-proxy-middleware');

module.exports = function(app) {
    app.use(
        proxy('/api', {
            target: 'http://localhost:8080',
            changeOrigin: true
        })
    );
};

• setupProxy.js filter(/api 부분)를 createProxyMiddleware가 아닌, use의 첫 인자로 넣어보기

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function (app) {
    app.use('/api',
        createProxyMiddleware({
            target: 'http://localhost:8080',
            changeOrigin: true
        })
    );
};

• setupProxy.js의 함수 끝에 app.listen(3001); 추가

MongoDB를 로컬에서 컨테이너로 실행하고 MongoDB에 데이터가 제대로 들어갔는지 확인하고 싶다고 @leeseungmin4966 이 말해서 다른 사람도 궁금할까봐 관련 이슈를 만듬

1. CLI
   run_docker.sh를 실행하면 mongo 컨테이너가 생기는데 여기에 docker CLI로 접속해서 mongosh 커맨드를 입력하면 mysql을 터미널에서 사용하듯이 확인 할 수 있다.

mongosh의 기본적인 사용방법은 구글림 참조

2. MongoDB Compass
   Compass를 이용해서 데이터베이스를 GUI 툴로 다룰 수 있다.
   이를 위해선 docker-compose.yml에서 아래의 port 및 하위 주석을 해제하고 이 후, server/README.md를 따르면 된다.
   https://github.com/BEOKS/DicomProject/blob/79fb2cb45a0a412fd0618e8567f96a8423fc93cf/server/docker-compose.yml#L26

현재 @leeseungmin4966 이 맥에서 compass로 접속하는데 Authentication Error가 발생하는 문제가 있다. (본인은 잘 접속 됨)

[
  {
   "stored_dicom_id": 145125,
    "anonymized_id": 1028011,
    "age": 53,
    "modality": "MG",
    "manufacturer": "HOLOGIC, Inc.",
    "manufacturerModelName": "Lorad Selenia",
    "class\nnon-pCR: 0 pCR: 1": 0,
    "left: 0\nright: 1": 1,
    "ER": 1,
    "PR": 1,
    "HER2": 1,
    "non-IDC: 0\nIDC: 1": 1,
    "compressionForce": 173.5019
  },
  {
   "stored_dicom_id": 145135,
    "anonymized_id": 1106526,
    "age": 56,
    "modality": "MG",
    "manufacturer": "HOLOGIC, Inc.",
    "manufacturerModelName": "Lorad Selenia",
    "class\nnon-pCR: 0 pCR: 1": 1,
    "left: 0\nright: 1": 0,
    "ER": 0,
    "PR": 0,
    "HER2": 0,
    "non-IDC: 0\nIDC: 1": 1,
    "compressionForce": 115.6019
  },
...
...

클라이언트와 서버 사이에서 전달되는 메타데이터는 위 와같은 형식의 json으로 구성될 예정이니 기능 구현 때 참조 바람

https://www.notion.so/Dicom-f51d59ba23904b5dbef9c22d18166132
https://www.notion.so/Dicom-35e2514b86b042a082cafda92396d253

Task: #36 , #37 , #38

개발을 시작하기 위해서 Spring 서버 초기화 및 개발 환경 설정을 실시합니다.

이 이슈는 개발 가이드를 위한 예시입니다.

Docs : https://www.notion.so/Sprint-Example-8710806b9f964bbeabbcc358cc4949b3

1. util 등의 부가적인 함수들은 새로운 파일로 모아서 관리하기
2. JSX를 길게 작성해야 한다면 새롭게 큰 Component를 파일로 만들어서 관리하기

Epic : #27

SPRINT2 회의 기반으로 MongoDB 스키마 구성과 FlowChart 시각화

Task 번호 : #70

• MongoDB 스키마

• FlowChar

• 분석 내용 :

현재 DB 스키마를 분석하면서 생각한 점을 말해보겠다.

1. Mongo의 도큐먼트 구조는 크게 2가지가 있다. 임베디드(Embedded) 방식, 레퍼런스(References) 방식으로 나누어 진다. 현재 프로젝트 스키마를 보면 project 컬렉션 아래 project 도큐먼트의 필드값으로 metadata_list를 가지는 전형적인 임베디드(Embedded) 방식이다.
   그래서 임베디드(Embedded) 방식의 특징을 살펴보면, 임베디드(Embedded) 방식은 반정 규화 모델로서 데이터의 정합성 문제에 민감하다. 즉, 지금과 같은 구조로는 한 환자의 metadata가 여러 프로젝트에 존재할때 특정 project에서만 metadata의 수정이 있을 시 전체 DB에서 정합성이 깨지는 문제가 발생 할 수 있다.

2. 도큐먼트의 최대 크기는 16 MByte이며 최대 크기 이하로 도큐먼트를 관리해야 한다. 그런데 지금과 같은 구조는 metatdata를 한 project document 내에서 처리하기에 metatdata_list의 양이 늘어나 도큐먼트의 최대 크기를 넘어버리는 경우가 발생 할 수 있다.

3. 반면 좋은 점으로는 임베디드(Embedded) 방식은 레퍼런스(References) 방식과 달리 참조를 통해 접근하지 않기에 조회 시 성능이 비교적 좋다.

문제점을 정리하자면,

1. 한 환자의 metadata가 project마다 존재할때, 수정시 데이터의 정합성에 문제가 생긴다.
2. 현재 스키마 구조는 임베디드(Embedded) 방식으로 구성되며 도큐먼트에 포함하는 데이터가 증가할수록 도큐먼트의 크기도 증가하여 디스크 I/O (수정,삭제)시 성능 저하 발생 및 도큐먼트의 최대 크기를 초과 시 저장이 불가능할 수 있음

• 해결방안에 대한 생각 :

1번 문제)
환자의 metadata를 project 별로 관리 하는 것이 아니라, patient collection에서 관리하고 project에서는 patient_id로 patient에 저장된 metadata를 참조하는 방식으로 바꾼다면 문제 해결 가능 할 것이라 생각 됨. 그런데 참조 방식으로 인해 조회 성능 저하 발생 예상됨.

2번 문제)
1번문제 해결방안에서 제시했듯이 메타데이터를 환자 컬렉션에서 관리하면 환자 아이디만 metadata_list에 저장되기에 도큐먼트 최대 용량은 안넘을 것이라 생각되긴 하지만 혹시 걱정되면 metadata_list를 정규화(분리) 시켜 줄 필요가 있다고 생각함

window의 경우 도커 네트워크 도메인이 dicomserver_db_1, dicomserver_backend_1로 정의되지만,
mac의 경우 dicomserver-db-1, diccomserver-backend-1로 정의된다

상황

./run_docker.sh

• JDK 버전 17로 맞춤
• 환경변수 설정 완료

오류 화면

코멘트

JDK 버전 문제인 것 같은데 이것저것 설정해봐도 오류가 사라지지 않아요! 헬프...
@BEOKS

미들웨어 서버로 전송하기 전에 클라이언트 단에서 Dicom 파일 익명화 처리가 필요하다.

추가되는 project collection에 따른 DB 설계 및 API 구성

Spring 서버 개발을 위한 환경 변수 및 기본 종속성을 설정한다.

1. <metaTable data={'data.json'}>
2. 선택한 row 데이터 가져오기

const [selectedPatientInfo, setSelectedPatientInfo] =useState()
<DicomTable data={json} setSelectedRow={setSelectedPatientInfo}>

https://www.notion.so/DicomWithCSV-API-6526bd15c89f46a5988661b754204f2e

Why

Dicom Server와 MongoDB는 인증된 사용자만 접근할 수 있어야 한다. 그러나 Dicom Server는 인증 기능이 없기 때문에 미들웨어를 통한 Proxy Setting이 필요하다.

How

Way 1. Dicom Server container에서 MiddleWare와 MongoDB IP 접근만 허용하기.
Way 2. Docker Network를 통해서 컨테이너 간 통신만 가능하도록 설정하기.

What

MiddleWare에서만 데이터베이스에 접근 가능한 안전한 환경 구현

1. Spring 서버를 기본 프로젝트 구조로 초기화 합니다.
2. 실행이 원활한지 확인합니다.

다이콤 파일 업로드 기능 구현하기. 이때 다이콤 파일의 메타데이터는 전처리가 필요하다. 이는 교수님이랑 논의해볼것

기존 SPRINT2.1버젼 MongoDB 스키마의 Document Maximum size 문제를 해결하기 위한 스키마 구성.

task : #70

아래 그림을 통해 스키마를 비교할 수 있다.

• SPRINT2.1버젼

• SPRINT2.2버젼

개선점 :

기존 SPRINT2.1버젼 스키마의 구성에서 보면 project document 내에 metadata들이 array 형식으로 들어온다. 이렇게 구성 될 시 Unbounded Array가 되기에 MongoDB의 Maximum size 16MB 의 크기를 넘게 되는 문제와 더불어 수정 삭제 혹은 조회시 Array를 linear search해야하는 비용이 발생하게된다.

SPRINT2.2버젼은 이를 개선 하기 위해 기존 SPRINT2.1버젼의 project document 내에 metadata array를 metadata collection으로 분리 시켰다. 이를 통해 좀더 Entity별로 확실한 구분이 가능해졌고 array 가 아닌 document 단위로 metadata를 관리할 수 있게 된다 (document 최대 크기를 넘는 가능성의 이슈가 없어짐). 추가적으로 추후 유저관련 collection을 추가하는 작업 등 데이터베이스의 스키마 확장성 측면에서도 더 효율적일 듯 하다.

참고자료 (MongoDB 공식문서) : https://docs.atlas.mongodb.com/schema-suggestions/avoid-unbounded-arrays/

• 다운로드 버튼 클릭 시, 선택된 PatientID를 로드
• 각 ID에 대한 다운로드 요청 API를 실행
• 다운로드 에러 발생시 에러메시지를 출력

Problem?

기존 계획에는 아래와 같이 메타데이터를 테이블로 표시하고, 각 행을 클릭하면 환자의 이미지를 보여주는 형식으로 진행하려고 하였으나. 이 부분에서 논리적 오류가 발생

Why?

1. 메타 데이터는 Patient ID별로 데이터를 분류한다.
2. 이미지 뷰어는 Study ID별로 데이터를 분류한다.
   즉, 분류 기준이 종속적이라 메타데이터에서 하나의 행을 클릭한다고 이미지 뷰어를 확인 할 수 있는게 아님.

Solution?

Study ID는 Patient ID의 하위 계층이므로 아래와 같이 테이블을 작성해야 할 듯하다.

example

https://demos.telerik.com/kendo-ui/grid/detailtemplate

How?

1. Patient ID가 소속된 Study UID 리스트를 불러오는 API가 필요하다..

여기서 찾고자 하는 StudyInstanceUID와 검색에 사용되는 PatientID는 orthanc 서버에서 할당되는 UUID가 아니라 Dicom 파일 헤더에 포함되어있는 것을 의미함.

2. 프론트에서는 메타데이터의 Row를 클릭할 때마다, 서버에 StudyInstance UID 리스트를 호출하고 결과를 위 예시처럼 반영한다.

https://alpine-freezer-d6f.notion.site/Day3-a041ac1923c54182a3d2bfd51b87f98c

Related Tasks : #69 #70 #71 #72 #73 #74

문제 상황 : 메타데이터 클래스, dto 클래스에 json 속성 값을 필드로 넣어서 전달해주려고 하면 매 프로젝트마다 다른 속성 값들이 있기 때문에 클래스들을 자동으로 생성해줘야 한다. 사용할 만한 라이브러리(jsonschema2POJO)를 찾아 사용해보려 했으나, gradle 버전과 groovy 호환성 때문에 실패했다. 이에 속성 값 대신 아예 json 객체를 넣어 전달하는게 어떻겠냐는 얘기가 나왔다.

데이터 형식

Dicom 서버에서 자체적으로 생성되는 ID를 메타데이터에 추가해서 MongoDB에 추가해주어야함.

1. 현재 프로젝트 Drawer 내용을 새로운 js파일을 만들어서 컴포넌트로 관리하기 -> #61 의 일부
2. 하드 코딩을 수정, Drawer가 Project List(ex. { 'project_list' : [MR project, US project ...] })를 props로 받아서 프로젝트 리스트를 보여주도록 처리하기
3. 프로젝트 생성 버튼을 프로젝트 리스트 최 하단에 추가
4. (이 후, project list 내용을 서버에 API로 요청해서 진행예정)

Epic : #27

React에서 뷰어 관련 디렉토리를 선언 후 내부에 컴포넌트를 작성하여 임베딩이 가능하도록 코드 작성이 필요하다

1. 프로젝트별로 patient id가 포함된 메타 데이터 테이블을 보여준다.
2. 테이블 행 클릭 시 study id 테이블(이하 서브테이블)을 보여준다.
   • 서브테이블 컬럼에는 study id만 포함한다.
3. 서브테이블 행 클릭 시 뷰어 페이지로 리다이렉션한다.

metadata collection 접근시 index 사용의 필요성에 대한 생각

epic : #75

task : #70

현재 MongoDB내 metadata collection에서 각 metadata들이 몽고에서 부여한 유니크한 ObjectId로 document를 구성하고있다.

추가적으로 이번 SPRINT2 버젼을 통해 project collection이 생기게 되었고, projectId를 기반으로 metadata를 다룰일이 많아졌다.

구체적인 예시로,

1. projectId를 기반으로 전체 metadata에서 조회 해야할 일이 빈번하다.

2. 추가적으로 project 삭제시 관련 metadata들도 삭제 되어야 한다.

위와 같은 이유로 metadata collection에 projectId 를 기반으로 indexing을 해줄 필요가 있다고 생각한다.
( MongoDB는 index의 사용을 B-tree 를 통해 수행한다. )

아직 많은 양의 데이터가 쌓이지 않아 성능 비교를 하지 못했는데, 어느정도 데이터가 쌓이면 indexing을 통한 성능 비교를 통해 사용여부를 결정 하면 될 듯하다.

Multipartfile로 받아서 RestTemplate으로 orthanc에 업로드하는데에는 성공했음

받아온 response 값은 다음과 같음
<200,[Connection:"keep-alive", Keep-Alive:"timeout=1", Content-Length:"0"]>

여기서 추가적으로 Body로 올라간 파일의 정보를 받아야되는데, response로 받아지지 않음..
API Tester로는 Body로 올라간 파일에 대한 결과값이 json형식으로 반환됨

[현재 결과]

[API Tester]

The title says it all

지금 현재 구현된 다운로드 API는 Dicom file ID로 하나의 파일만을 다운로드함

이번 Sprint에서 Patient별로 Dicom file을 관리하므로
PatientID에 해당하는 Dicom file 전체를 zip 파일로 다운로드하는 API구현을 목표로 함

Epic : #75

Purpose :

SPRINT2 BackEnd Merge를 위한 Branch

Task :

1. Patient Id를 받으면 StudyUID List를 반환하는 API 생성 ( #72 )

2. 프로젝트 생성 및 전체 조회 API 구현 (#70 )

https://www.notion.so/Dicom-f51d59ba23904b5dbef9c22d18166132

Task: #28

프로젝트를 새로 추가할 때마다 이에 맞는 메타데이터가 구성되어야 한다.
이 때 Spring boot Entity 클래스는 동적으로 생성되어야 한다.

HashMap으로 메타데이터를 정의하는 방법도 있지만 이렇게 되면
MongoDB에서 메타데이터 기반으로 쿼리 서치를 할 때 문제가 발생한다.

현재 단계에서는 인덱싱을 신경 쓰지 않아도 되지만 이후 프로젝트가 복잡해지면 해결책이 필요하다.