...

1. The mountpoint-registrar bundle uses 1 configuration file (it is located in the $ODL_HOME/etc directory by default) - 
   1. dmaapmountpoint-vesmsg-listenerregistrar.properties - This file contains a property key by the name - subscriptions and its values are fully qualified Java class names and consumer properties file names separated by : (colon) and ; (semicolon) Ex: subscriptions=org.onap.ccsdk.features.sdnr.wt.mountpointregistrar.impl.DMaaPPNFRegVESMsgConsumer:pnfRegVESmsgConsumer.properties
      In the example above, the subscriptions property value contains 2 parts separated by a : (colon). The value before the : (colon) contains a fully qualified Java class name which implements the DMaaPVESMsgConsumer class. The value after the : (colon) contains a consumer properties file as understood by DMaaP consumer implementation. There can be any number of "Java class : consumer properties file" values separated by a ; (semicolon) for the subscriptions property. Note: the example value shown above is identical to the value in the dmaap-vesmsg-listener.properties file shipped with the bundle and this should not be changed. 
   The consumer properties file contains information about the Kafka topic, consumer ID, group ID, authorization information etc. This bundle ships a consumer properties file with the name pnfRegVESmsgConsumer.properties and this file is by default
   1. Contains the consumer Java class name and the consumer properties. By default the HTTPNOAUTH transport type is used by the consumer. For other applicable transport types and their corresponding properties, please refer to - Feature configuration requirements. This properties file is auto-generated in its entirety if it does not exist. If certain properties are missing in an already existing file that is present in the $ODL_HOME/etc directory
   . Example below.

...

1. 1. before the bundle starts, the missing properties are included automatically into the existing file. The file contains the following properties - 

[general]
dmaapEnabled=false
pnfRegConsumerClass=org.onap.ccsdk.features.sdnr.wt.mountpointregistrar.impl.DMaaPPNFRegVESMsgConsumer
TransportType=HTTPNOAUTH
host=onap-dmap:3904
topic=unauthenticated.VES_PNFREG_OUTPUT
contenttype=application/json
group=myG
id=C1
timeout=20000
limit=10000

The "dmaapEnabled" property is an important one to be aware of. By default it is set to "false", it means that DMaaP is not enabled in the system and hence we do not want the mountpoint-registrar bundle to poll for messages. When DMaaP is running, set the "dmaapEnabled" property to "true", set "host" property to the DMaaP host IP Address/Hostname and saving the file will automatically start the PNFRegistration consumer to consume messages from the DMaaP topic.

Usage

1. Install DMaaP as per instructions in - How to set up a local DMaaP installation in Docker for testing. This is based on Amsterdam. The latest DMaaP repository can be retrieved using information in - Resources and Repositories
2. Installing and starting DMaaP as per the instructions in (1) above brings up 3 docker containers - dmaap:localadapt , dockercompose_kafka and wurstmeister/zookeeper
3. Install VESCollector. Detailed instructions are at - https://github.com/onap/dcaegen2-collectors-ves. The DMaaP topics that VESCollector manages are present in etc/DmaapConfig.json file. cambria.topic refers to the topics that VESCollector manages. cambria.hosts value should match the IP Address/Hostname of the DMaaP instance.
4. Once we have DMaaP, Kafka, zoopkeeper and VESCollector running, we can send pnfRegistration VES message using the pnfRegister.sh script located at https://git-highstreet-technologies.com/highstreet/sdnr-interfacing-aai-dcae. The "config" file has to be updated with the correct DCAE VES Collector communication end point
5. On executing the pnfRegister.sh script (ex: pnfRegister.sh 1234), a VES message is sent to the VESCollector which processes the VES message and checks for conformance as per the JSON schema and if everything is fine, puts the message in the DMaaP topic
6. Deploy SDN-R and check if the mountpoint-registrar bundle is running correctly by looking for the following messages in the karaf.log - 
   1. DMaaPPNFRegVESMsgConsumer received ResponseCode: 200
   2. DMaaPPNFRegVESMsgConsumer received ResponseMessage:
   3. No data received from fetch. Pausing 5000 ms before retry
7. Once the mountpoint-registrar bundle is running correctly, it starts to consume any VES messages coming on the topic and creates a mountpoint in SDN-R by parsing the information in the VES Message. The created mountpoint can be seen by logging into the ODLUX GUI. 
8. Currently the created mountpoint uses SSH for communicating with the PNF. A TLS based mountpoint implementation is in the works.

...