이 위시리스트 요청은 무엇에서 비롯되었나요? 테이블/열 변경 시 워크플로 빌더 작동에 어려움이 있었기 때문입니다(테이블을 찾을 수 없음, 열을 찾을 수 없음 등).
어떤 개선점을 원하시나요? 워크플로 빌더가 변수를 더욱 자연스럽게 활용했으면 좋겠습니다. JMP 백엔드에서 기본적으로 변수를 사용할 수 있게 되는 것은 물론, 사용자 인터페이스(GUI)에서도 변수를 활용할 수 있게 되기를 바랍니다.
워크플로를 실행하거나 공유할 때 테이블 이름 같은 것이 변경되면 JMP는 사용자가 차이점을 수정할 수 있는 기회를 잘 제공합니다. 하지만 프로세스 단계 중 어느 부분에서 변경 사항을 수정해야 하는지 명확하지 않은 경우가 많아 저를 포함한 사용자들이 워크플로를 중단하고 다른 방법을 시도하는 경우가 있습니다(잠깐, JMP가 예상했던 게 뭐지? 어떻게 수정하지? 등).
그리고 제가 무슨 일이 일어나는지 확인하러 가면, 오류가 있거나 동적으로 처리되어야 할 부분이 있을 수 있습니다. 그러면 이제 열이나 데이터 테이블 참조 같은 것이 하드코딩된 모든 부분을 하나하나 수정해야 합니다. JMP가 처음부터 변수로 설정해 놓았더라면, 한 곳만 수정하면 됐을 텐데 말이죠.
또한, 워크플로를 시작하기 전에 데이터 테이블 이름이나 열 이름과 같은 요소들이 가변적일 수 있다는 것을 알고 있을 수 있습니다. 워크플로에 변수를 쉽게 추가하여 기본값으로 설정하거나 사용자에게 입력을 요청할 수 있도록 하는 것은 매우 유용합니다.
이 아이디어가 왜 중요할까요? 워크플로 빌더는 매우 훌륭한 도구이며, 스크립팅에 대한 배경 지식이 많지 않아도 자동화를 가능하게 해줍니다. 특별한 변경 사항이 없다면 워크플로 빌더는 완벽하게 작동합니다. JMP는 이미 잠재적인 차이점을 잘 처리하고 있으며, 더 나은 변수 처리를 추가하면 이러한 성능을 한 단계 더 끌어올릴 수 있습니다. 또한, 프로세스 자체에 변수 처리 기능이 내장되면 스크립트를 내보낼 때 하드 코딩된 값 대신 변수를 설정하고 사용하는 것이 명확해지므로 스크립트 사용에 익숙해지는 데 도움이 될 것입니다. 유일한 주의 사항/변경 사항은 워크플로 빌더 JSL 내보내기가 자체 작업 공간을 생성해야 할 수도 있다는 점입니다(변수 충돌을 방지하기 위해 거대한 '로컬' 래퍼를 만드는 것은 바람직하지 않습니다).
저도 동의합니다. 향상된 로그와 WFB를 좀 더 일반화할 수 있는 방법이 필요합니다. 한 가지 쉬운 해결책은 향상된 로그에서 명시적인 테이블 참조 대신 Current Data Table()을 사용하도록 하는 옵션을 추가하는 것입니다. 제가 사용해 본 결과, 향상된 로그와 WFB에 사용된 JSL 코드의 약 90%가 이와 같은 방식으로 수정될 수 있었습니다.
