-
Notifications
You must be signed in to change notification settings - Fork 30
UCI Installation
PSQL_DB_URL=postgres://postgresql:yoursupersecret@comms:5432/comms
PSQL_DB_URL_DEV=postgres://postgresql:yoursupersecret@localhost:55001/comms
HASURA_GRAPHQL_DATABASE_URL=postgres://postgresql:yoursupersecret@comms:5432/comms
HASURA_GRAPHQL_ENABLE_CONSOLE=true
HASURA_GRAPHQL_ENABLED_LOG_TYPES=startup, http-log, webhook-log, websocket-log, query-log
HASURA_GRAPHQL_ADMIN_SECRET=4GeEB2JCU5rBdLvQ4Abeq
POSTGRES_PASSWORD=yoursupersecret
POSTGRES_USER=postgresql
POSTGRES_DB=comms
DATABASE_DEBUG=true
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_PASS=foobared
KAFKA_HOST=127.0.0.1:9092
KAFKA_USER=admin
KAFKA_PASS=cttsamagra
KAFKA_PORT=9092
docker-compose up -d
should setup the development environment for comms-manager.
It will show Kafka connections error. Ignore them right now. We will set them up in the next step. Once the docker is up, you should be able to go to http://localhost:9999 to see that the server is up.
The setup also depends on a file called vaultDataMock.json
which mocks the credentials repository. This will be removed from future releases. [ETA-17/March/2020] Issue#3
Getting the docker-compose file
wget https://raw.githubusercontent.com/samagra-comms/deploy/master/docker-compose.yml?token=ABYSAOCWHQQHSEMGGYRIXSDAJ2MBU
docker-compose up -d
It will setup the comms core components and databases.
Since this would require to call APIs on the local server, it would be easier through the postman collection.
-
A) Adding a Transformer Use the APIs in the Postman collection to create two transformers, a generic
rest-service
one and anODK
one. -
B) Adding a UserSegment Use the APIs to setup a user segment. It could either by
gql
or arest-service
but the response should be JSON with the following format -
//For all users
{
"data":{
"users":[
{
"mobilePhone":"xxxxxxxxxx"
}
]
}
}
Note The key mobilePhone is mandatory. All other keys can be moved For now, we can keep setup the user segment similar to the one that is provided in the API Sample request.
- C) Adding an Adapter Adapters follow the following structure
{
"data": {
"channel": "WhatsApp",
"provider": "gupshup",
"config": {
"phone": "9876543210",
"HSM_ID": "2000193031",
"2WAY": "2000193033",
"credentials": {
"vault": "samagra",
"variable": "gupshupSamagraProd"
},
},
}
}
For Whatsapp, the above details are provided by the service provider during registration. For now we can use Samagra's config for the same.
-
D) Adding a Conversation Logic For this exercise let's start with a simple conversation logic-based out of an ODK form. You will need to upload the form to the ODK server and add the formID here. The ODK transformer added in
A
will be used to fetch the ODK form so make sure you do the same. We have uploaded some sample forms to the Samagra ODK so let's pick one for this exercise =>ss_form_mpc
. Note the form link config is overridden if you provide the formID. Each CL (Conversation Logic) has an adapter setting. Since we are targeting users on whatsapp, we link it with the same adapter by adding the adapterID to it. -
E) Adding a Bot This is the last part of setting up a bot. A Bot comprises a
startingMessage
,name
to identify it,userSegment
to target or limit a bot to and an array of CLs.
Everything is setup except for the incoming webhook link [part of the adapter] that lets the server know in case of incoming messages. Currently, since there is just one upstream that we can configure on the provider's end, we duplicate the requests to multiple backends and has to be done manually. So please raise a request by sending an email to [email protected].
Initial Setup with Gupshup/Netcore
Adapter (sends bot response) => Gupshup => Whatsapp => [Delivery status/Response] => Webhook => Adapter