hi

pacs server clearcanvas 13.2 installed

tomcat 9 installet

weasis .war deploy tomcat

browser http://127.0.0.1:8080/weasis-pacs-connector/viewer download weasis.jnlp file

weasis.jnlp clik start weasis

how to integrate and run wesis clearcanvas ?

weasis config file

how do i change the weasis config file

Either through the URL parameter
&access_token=XXXXXXXXXXXX

Or in the http Header:
Authorization: Bearer XXXXXXXXXXXX

See https://nroduit.github.io/en/getting-started/weasis-protocol

Hi,

I'm trying to get the weasis-pacs-connector (6.1.3) to work with the DCM4CHEE 2.18.3 exclusively over HTTPS behind a reverse proxy.

The tomcat server is listening on port 8080 (HTTP only), but in front of that I have an nginx webserver which reverse-proxies back to 8080. Nginx currently listens on both 80 and 443.

It works fine for me if I allow both HTTP and HTTPS from the server, but I want to make all the traffic go over HTTPS. I have configured server.base.url, manifest.base.url, weasis.base.url, weasis.ext.url and arc.wado.url all to point to "https://server:443" (with appropriate suffix if required).

The jnlp (WebviewerBaseUrl = weasis:/weasis-pacs-connector/viewer) downloads, and the viewer opens.

However the '/wado....' urls to actually retrieve the images are going over HTTP.

So if I turn off HTTP on the front-end, the jnlp downloads but the images do not.

Is this possible to achieve? Am I missing a setting somewhere?

Thanks in advance,
Paddy

Add an option to turn off the new IID interface because it allows to get images at patient and study level independently of the combination of UIDs.

If the combination of UIDs is used at study level then the IID service must be turn off.

The IID service must be also consistent with the activation of the request at different levels (Patient, Study...)

Hello, I'm trying to implement a custom preset, because one of our hospitals uploads funky images and it's annoying to change the window/level for every single DICOM.

I tried adding the following line to the presets archive but it didn't show up as an option after opening the DICOM:
<preset name="HRSP" modality="MG" window="165" level="165"/>

Changing the modality to CT or RM made it show up and function as intended on DICOM's of those modalities.
I thought it might be the DICOM archive modality, but it seems it is correctly assigned as MG.

So, am I doing something wrong or is the problem really in the files?
Is there a way to implement a preset available for all modalities?

Thanks in advance!

EDIT: Sorry, confused this page with the weasis main page, will repost there.

Any suggestion will be appreciated. thx!

see https://groups.google.com/d/msg/dcm4che/Q37fRQPJSEA/-k6rUu2vBAAJ

I'm unable to deploy weasis-pacs-connector v6.1.1 on dcm4chee 2.18.3 psql.
After the restart I get this error in dcm4chee's server.log:

2017-08-24 12:11:09,660 ERROR -> (main) [org.jboss.deployment.MainDeployer] Could not create deployment: file:/opt/dcm4chee-2.18.3-psql/server/default/deploy/weasis-pacs-connecto
r.war
java.lang.UnsupportedClassVersionError: org/weasis/servlet/JnlpLauncher : Unsupported major.minor version 51.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
        at org.jboss.wsf.container.jboss42.JAXWSDeployerHookPreJSE.getEndpointBeans(JAXWSDeployerHookPreJSE.java:145)
        at org.jboss.wsf.container.jboss42.JAXWSDeployerHookPreJSE.isWebServiceDeployment(JAXWSDeployerHookPreJSE.java:104)
        at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:87)
        at org.jboss.wsf.container.jboss42.DeployerInterceptor.create(DeployerInterceptor.java:79)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at com.sun.proxy.$Proxy47.create(Unknown Source)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
        at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
...

I didn't change the defaults and set only the WebviewerNames to weasis.

Thanks in advance!

Build manifest with weasis-dicom-tools

Handle null encoding charset in some web containers

see #23

I am trying to install and configure to run with DICOMCloud (to test the WADO implementation with the Weasis viewer). I have followed the steps in the installation and Configuration settings of the readme and related links:
-JDK 1.8 ,Maven,TOMCAT and WeasisConnector installed
maven run with : mvn clean package

However I am unable to find the place where I configure the target WADO server. In my case it should be localhost:44301 which is the default for DICOMcloud

Do I also need to specify the urls for WADO-RS, QIDO-RS and STOW and/or WADO-uri somewhere
eg WADO-RS=localhost:44301/wado

or is a default being assumed (/wado, /qido ...

Would be really helpful to have a bit more documentation since the Weasis viewer is quite powerful, the WADO interface then allows it to connect to most PACSes.

The manager thread is interrupted but never dies.
Log:

2018-12-07 07:15:55,673 [ Thread-112] WARN m.t.ManifestManagerThread sleep interrupted
2018-12-07 07:15:55,673 [ Thread-112] WARN m.t.ManifestManagerThread sleep interrupted
2018-12-07 07:15:55,673 [ Thread-112] WARN m.t.ManifestManagerThread sleep interrupted
2018-12-07 07:15:55,674 [ Thread-112] WARN m.t.ManifestManagerThread sleep interrupted
2018-12-07 07:15:55,674 [ Thread-112] WARN m.t.ManifestManagerThread sleep interrupted
...

It should be not so difficult to have the ability to query multiple PACS using a single installation of weasis-pacs-connector.

I managed to run weasis-pacs-connector inside Tomcat. It works as expected.
In order to query many pacs server, I have deployed many weasis-pacs-connector with different names, each with a weasis-connector-default.properties file inside it, like a webapp for each PACS server I need to query.
Something like this:

/path/to/tomcat/webapps/weasis-pacs-connector-rx
/path/to/tomcat/webapps/weasis-pacs-connector-mr

I'm not a developer, but looking at the source code it should not be too difficult to read more than a configuration file. For instance, in order to query a specific server and read a specific configuration file, we can add a new property in the URL, like for instance
http://server:8080/weasis-pacs-connector/manifest?patientID=12345&**server**=PACS1
or
http://server:8080/weasis-pacs-connector/manifest?patientID=6789&**server**=PACS2

So, looking at the server value we can read the related properties file containing pacsAET, pacsHost, pacsPort, wadoQueriesURL, etc.

wrong posting

Sorry

http://weasis//$dicom:rs%20--url%20%22https://106.13.233.252:8443/dcm4chee-arc/aets/DCM4CHEE/rs%22%20-r%20%22patientID=583295%22%20--query-ext%20%22&includedefaults=false%22

this my docker-compose.yml

version: "3"
services:
ldap:
image: dcm4che/slapd-dcm4chee:2.4.50-23.0
logging:
driver: json-file
options:
max-size: "10m"
ports:
- "389:389"
- "636:636"
env_file: docker-compose.env
volumes:
- /var/local/dcm4chee-arc/ldap:/var/lib/openldap/openldap-data
- /var/local/dcm4chee-arc/slapd.d:/etc/openldap/slapd.d
keycloak:
image: dcm4che/keycloak:11.0.3
logging:
driver: json-file
options:
max-size: "10m"
ports:
- "8880:8880"
- "8843:8843"
- "8990:8990"
- "8993:8993"
env_file: docker-compose.env
environment:
HTTP_PORT: 8880
HTTPS_PORT: 8843
MANAGEMENT_HTTP_PORT: 8990
MANAGEMENT_HTTPS_PORT: 8993
KEYCLOAK_WAIT_FOR: ldap:389
depends_on:
- ldap
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone/timezone:/etc/timezone:ro
- /var/local/dcm4chee-arc/keycloak:/opt/keycloak/standalone
db:
image: dcm4che/postgres-dcm4chee:13.1-23
logging:
driver: json-file
options:
max-size: "10m"
ports:
- "5432:5432"
env_file: docker-compose.env
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone/timezone:/etc/timezone:ro
- /var/local/dcm4chee-arc/db:/var/lib/postgresql/data
arc:
image: dcm4che/dcm4chee-arc-psql:5.23.0-secure
ports:
- "8080:8080"
- "8443:8443"
- "9990:9990"
- "9993:9993"
- "11112:11112"
- "2762:2762"
- "2575:2575"
- "12575:12575"
env_file: docker-compose.env
environment:
WILDFLY_CHOWN: /opt/wildfly/standalone /storage
WILDFLY_WAIT_FOR: ldap:389 db:5432
depends_on:
- ldap
- keycloak
- db
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone/timezone:/etc/timezone:ro
- /var/local/dcm4chee-arc/wildfly:/opt/wildfly/standalone
- /var/local/dcm4chee-arc/storage:/storage

this my docker-compose.env

ARCHIVE_HOST=106.13.233.252
STORAGE_DIR=/storage/fs1
POSTGRES_DB=pacsdb
POSTGRES_USER=pacs
POSTGRES_PASSWORD=pacs
AUTH_SERVER_URL=https://106.13.233.252:8843/auth
server.base.url=https://106.13.233.252:8843

I also the left menu Configuration > Devices > dcm4chee-arc > Extensions > Edit extension > Child Objects > Web Applications > DCM4CHEE

IID_PATIENT_URL=weasis://$dicom:rs --url "{{qidoBaseURL}}{{qidoBasePath}}" -r "patientID={{patientID}}" --query-ext "&includedefaults=false" -H "Authorization: Bearer {{access_token}}"
IID_STUDY_URL=weasis://$dicom:rs --url "{{qidoBaseURL}}{{qidoBasePath}}" -r "studyUID={{studyUID}}" --query-ext "&includedefaults=false" -H "Authorization: Bearer {{access_token}}"
IID_URL_TARGET=_self

but the weasis is not display

Using minimal dcm4chee-arc-light 5.29.0, deployed with docker-compose and weasis-pacs-connector 7.1.2.

IID_PATIENT_URL=../../weasis-pacs-connector/weasis?patientID={{patientID}}&cdb
IID_STUDY_URL=../../weasis-pacs-connector/weasis?studyUID={{studyUID}}&cdb

by the docs.

The problem is in this url that the connector gives to the browser:
weasis://$dicom:get -w "http://192.168.94.35:8080/weasis-pacs-connector/RequestManifest;jsessionid=Iwd6k2ilkvJgIHqmACNhyOq71aYvjDWq9dLpo2oH.bc985330fa84?id=2" $weasis:config cdb cdb-ext="http://192.168.94.35:8080/weasis-ext",
particularly in the presence of cdb-ext parameter. With it, the local native client crashes with "Failed to launch JVM" error.

I didn't manage to find anything about it in the docs (mostly why I type this issue), but i did a workaround myself, as it's similar to nullifying the cdb parameter - just nullify cdb-ext as well, e.g.:

IID_PATIENT_URL=../../weasis-pacs-connector/weasis?patientID={{patientID}}&cdb&cdb-ext
IID_STUDY_URL=../../weasis-pacs-connector/weasis?studyUID={{studyUID}}&cdb&cdb-ext

and the client starts and opens images as it should.

That said, besides weasis-pacs-connector I also first installed weasis.war and weasis-ext.war, but then saw that weasis.war is discontinued and deleted both weasis.war and weasis-ext.war. Not sure if that might've messed up the things in the first place somehow.

I'm facing a new issue when i clicked the eye icon in the UI of the archive (nothing happens).
I've checked in 3 different browsers with the same result.
i've change the property value to this: IID_STUDY_URL=../../weasis-pacs-connector/IHEInvokeImageDisplay?requestType=STUDY&studyUID={}&access_token={}&target=_blank, to open a new windows, then the response is 302, but after that the call to weasis:// is canceled and weasis doesn't open at all, when i hit the eye icon.
PD: when i redeploy the weasis-pacs-connector on the logs everything looks fine too.

Something has changed between 7.1.1 and 7.1.2?
With the same configuration the behavior is different: in 7.1.1 it works, in 7.1.2 doesn't work anymore.

arc.config.list=arc1,arc2 in weasis-pacs-connector.properties (and corresponding arc1 and arc2 files), it seems that they are not taken in consideration and the baseUrl= indeed contains the url of the server where weasis-pacs-connector is deployed, instead of arc.wado.url= specified in the archive properties files.

Until dcm4chee-arc 5.31.0 + WildFly 26.1.3.Final
http://localhost:8080/weasis-pacs-connector/manifest?studyUID={}
I was able to display the image on weasis by getting the XML manifest with a description like this and using the weasis command $dicom:get
But the current dcm4chee-arc 5.31.2 requirement is unable to get the manifest with WildFly 29.0.1
This seems to be caused by the Jakarta EE Version used in WildFly being changed from Jakarta EE 8 to Jakarta EE 10.
Where should I modify the weasis-pacs-connector source to be able to obtain the XML manifest?

what should be the location of dicom-dcm4chee.properties and weasis-pacs-connector.properties files in Tomcat 7?

The property of combination of UIDs has no effect

Question about whether a feature is available:

If the machine running the weasis-pacs-connector is accessed from another machine on the same network, is it possible to have the
weasis:// URI launch on the machine running the weasis-pacs-connector (as opposed to the machine it is accessed on)?

For example: if the machine at 10.0.0.26 is running the weasis-pacs-connector, but then a browser on the machine 10.0.0.50 navigates to the URL http://10.0.0.26:8080/weasis-pacs-connector/weasis?studyUID=2.16.124.113577.1.1712011672.20140519143659.692.0&cdb, is it possible for WEASIS to open on 10.0.0.26 (not 10.0.0.50)?

It doesn't currently appear possible, but wanted to check. Thanks!

@bryanc806

As the wado url depends on the choosen AET

arc.wado.url=${server.base.url}/dcm4chee-arc/aets/DCM4CHEE/wado

should be changed to

arc.wado.url=${server.base.url}/dcm4chee-arc/aets/${arc.aet}/wado

In dicom-dcm4chee.properties file variable ${server.base.url} returns the URL with IP and PORT but there is no way to get IP of server only.Using the variable ${server.host} doesn't work.Kindly incorporate a way to fetch only IP using a variable like ${server.base.ip}

Applet has been removed from Java 11 and most of the browsers block Java plugin for older Java versions.

Hi!

I am currently trying to integrate weasis-pacs-connector (v 5.0.1) with the Bahmni EMR. I already did succeed with a little workaround, but I want to overcome the issue I am having. By default the Bahmni EMR calls a prepared link to a viewer as HTTP HEAD:

"pacsImageUrl":"https://10.181.135.102:8443/weasis-pacs-connector/IHEInvokeImageDisplay?requestType=STUDY&accessionNumber={{orderNumber}"

Unfortunatley, this HTTP HEAD request results in an error 404 from /weasis-pacs-connector/jnlpBuilder

Changing the HTTP type to GET works fine, but this is not supported by Bahmni.

So in my opinion, the issue must be in WeasisLauncher.java, where the HTTP GET, POST and HEAD are treated different. Could you explain what the intention behind this is?

For more information see my thread in the Bahmni discussion.

Looks like dcm4chee 2.18.3 can run with jdk 1.8 with small changed to deploy/jmx-console.war/inspectMBean.jsp
(change replace(""",""") to replaceAl(""",""")).
Can I use weasis pacs-connector master branch if I use jdk 1.8 or is servlet container support still a problem with dcm4chee-2.18.3 and jdk 1.8?

This is a feature request.

Let's say I have one study in my PACS with accessionNumber ABC123. The behaviour I want to implement is:

When I call /weasis-pacs-connector/viewer?requestType=STUDY&accessionNumber=ABC123 I want the jnlp to download etc.

When I call any other accessionNumber, I do not want the jnlp to be downloaded. I want to respond with an HTTP error code, instead of the user opening weasis just to find out that the file does not exist.

What approach to you recommend to achieve this? Which classes to use etc.

Weais viewer not running but query reach to dcm4chee
steps : 1- deploy weasis.war,weasis-pacs-connector.war to wildlfy using http
configure dcm4chee by adding
IID_PATIENT_URL=../../weasis-pacs-connector/weasis?&patientID={}&target=_self
IID_STUDY_URL=../../weasis-pacs-connector/weasis?&studyUID={}&target=_self

Also for
IID_PATIENT_URL=http://localhost:8080/weasis-pacs-connector/weasis://$dicom:rs --url "http://192.168.1.7:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies" -r "&patientID=2168068" -r " --query-ext "&includedefaults=false"
IID_STUDY_URL=http://localhost:8080/weasis-pacs-connector/weasis://$dicom:rs --url "http://192.168.1.7:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies" -r "&studyID=1.2.840.113619.2.358.3.2831172914.667.1504680361.584" -r " --query-ext "&includedefaults=false"
Not query or open weasis viewer

also, how to enable logging in log server of dcm4chee arc (jboss wildfly) for weasis and weasis-pacs-connector

For dcm4hcee secure version 5.22.6 if i install weasis viewer locally (.deb package) :
if using http it open and running but if calling using https it open without any images and give error
"issue for certificate is : error in loading xml maifest from https://URL:8443/weasis-pacs-connector/RequestManifest?id=13"
"server response : javax.net.ssl.sshHandshakeException: PKIX path building failed: sun.security.provider.certpath"