Page Comparison

...

• Create a webservice and implement the appropriate WSDL for that adapter. These can be found in the CONNECT Webservices repository. As an example: DocumentQuery/src/main/resources/wsdl/AdapterDocQuery.wsdl for the Document Query Adapter.

• Change the InternalExchangeInfo.xml listing to point to your new webservice. Please note that you only need to change the respective Secured / Unsecured URL depending on which implementation you chose. Both Secured and Unsecured examples are shown below:

  Code Block
  language xml
  <ns2:endpoint> <ns2:name>adapterdocquery</ns2:name> <ns2:endpointConfigurationList> <ns2:endpointConfiguration> <ns2:url>http://localhost:8080/MyNewService/MyUnsecuredDocQueryAdapter</ns2:url> <ns2:version>LEVEL_a0</ns2:version> </ns2:endpointConfiguration> </ns2:endpointConfigurationList> </ns2:endpoint> <ns2:endpoint> <ns2:name>adapterdocquerysecured</ns2:name> <ns2:endpointConfigurationList> <ns2:endpointConfiguration> <ns2:url>https://localhost:8181/MyNewService/MySecuredDocQueryAdapter</ns2:url> <ns2:version>LEVEL_a0</ns2:version> </ns2:endpointConfiguration> </ns2:endpointConfigurationList> </ns2:endpoint>

  
  

•  Update the respective proxy file to use one of the provided web service proxies. Secured Proxy should be used for Secured Services, and Unsecured for Unsecured services. Note that you only need to change the Alias for the service. You do not need to modify the already existing beans contained in the file. In the example below we use the Secured adapter bean.

  Code Block
  language xml
  <!-- Beans defined for adapterdocquery --> <alias alias="adapterdocquery" name="adapterdocquerywssecured" />

  
  
  

Java Adapter Option

There is currently no standard when it comes to Java implementations as the use cases and availability of certain technology stacks will differ between adopters. A sample Java adapter and its respective proxy have been included in the CONNECT code base and can be used as a base for your implementation. While not recommended, the simplest way to introduce a Java adapter is to modify the Java reference adapter directly and bundle it with the CONNECT EAR. A more elegant approach is to implement a new proxy and implementation entirely. As the project uses Spring Injection for its services and adapters, the only requirement is that the new bean for your adapter and proxy can be found within the Spring Context for injection. In order to preserve the Event and Failure logging functionality, ensure you have marked your java entry method with the @AdapterDelegationEvent annotation and provided the respective builder classes.

For reference, all the configurable Java classes have been listed below. Entity proxies have also been included as the same steps apply for implementing these interfaces:

...

Once you have implemented your custom adapter, your new project must be put in as a dependency for the service you are implementing. This is so because your new beans (Created by the proxy definitions) will be in the same shared spring context as the rest of the other beans in the service. In the following snippet, we have added the "com.example" group ID and "MyCustomAdapter" artifact you have built earlier and installed into your local maven repository.

...