Απαντήστε στα μηνύματα WhatsApp με ένα chatflow του Flowise

Γιατί το Flowise χρειάζεται κάτι μπροστά του;

Επειδή το webhook της Meta και το API του Flowise χρησιμοποιούν διαφορετική μορφή. Η Meta επαληθεύει έναν προορισμό με ένα GET που πρέπει να επιστρέφει το hub.challenge ως ωμό σώμα και στη συνέχεια παραδίδει κάθε μήνυμα ως εμφωλευμένο JSON POST. Το Prediction API του Flowise αναμένει ένα POST στο /api/v1/prediction/ ακολουθούμενο από το αναγνωριστικό του flow, με ένα πεδίο question. Κανένα από τα δύο δεν θα προσαρμοστεί στο άλλο, γι' αυτό μεσολαβεί ένας δέκτης που μεταφράζει.

Ο δέκτης μπορεί να είναι ένας κόμβος Webhook του n8n, ένα route σε Python ή Node, ή οποιαδήποτε serverless συνάρτηση. Απαντά στο GET της επαλήθευσης, ελέγχει ένα μακρύ τυχαίο μυστικό που βρίσκεται στο URL του webhook, απαντά αμέσως 200 στη Meta και μετά κάνει τη δουλειά. Το μυστικό στο URL είναι ο έλεγχος ταυτότητας που λειτουργεί εδώ: η Meta υπογράφει τις παραδόσεις με το app secret του Tech Provider, το οποίο δεν μοιράζεται ποτέ, επομένως η κεφαλίδα X-Hub-Signature-256 δεν μπορεί να επικυρωθεί από τη δική σας πλευρά.

Πώς πρέπει ο δέκτης να καλεί το Prediction API;

Με το κείμενο του πελάτη ως question και τον αριθμό WhatsApp του πελάτη ως συνεδρία. Το Flowise δέχεται overrideConfig σε κάθε αίτημα, και το sessionId μέσα σε αυτό επιτρέπει στους κόμβους μνήμης να κρατούν μία συνομιλία ανά άτομο, αντί να ανακατεύουν όλους σε ένα νήμα. Ο αριθμός του αποστολέα από το payload του webhook είναι ένα σταθερό και φυσικό κλειδί γι' αυτό.

Αν το chatflow προστατεύεται με κλειδί API, ο δέκτης το στέλνει ως bearer token. Ορίστε το streaming σε false, εκτός αν ο δέκτης είναι φτιαγμένος να συναρμολογεί ροή, αφού το WhatsApp παραδίδει ένα ολοκληρωμένο μήνυμα και όχι ένα token τη φορά.

Η απάντηση φεύγει ως μήνυμα κειμένου του Cloud API από τον ίδιο αριθμό. Αυτό είναι δωρεάν και επιτρέπεται μέσα στο παράθυρο των 24 ωρών που άνοιξε το μήνυμα του πελάτη. Ό,τι θέλει να στείλει το flow αργότερα, όπως μια υπενθύμιση, πρέπει να είναι εγκεκριμένο template.

POST https://your-flowise-host/api/v1/prediction/<flow-id>
Authorization: Bearer <flowise-api-key>
Content-Type: application/json

{
  "question": "do you have anything friday?",
  "streaming": false,
  "overrideConfig": { "sessionId": "14155550188" }
}

Μπορεί ένας agent του Flowise να χρησιμοποιήσει τον MCP server του EasyCoexistence;

Όχι σήμερα. Το Custom MCP του Flowise συνδέεται σε έναν server Streamable HTTP με ένα URL και ένα σύνολο headers, συνήθως ένα στατικό bearer token που φυλάσσεται σε μια μεταβλητή του Flowise. Ο MCP server του EasyCoexistence κάνει έλεγχο ταυτότητας με OAuth, με σύνδεση μέσω προγράμματος περιήγησης και tokens που εκδίδει ο ίδιος, οπότε δεν υπάρχει στατικό κλειδί για να μπει σε header.

Η λύση που λειτουργεί είναι να αποφασίζει το flow και να στέλνει ο δέκτης. Το flow επιστρέφει το κείμενο που θα ειπωθεί, ή το όνομα ενός template όταν ο πελάτης είναι σιωπηλός για πάνω από μία ημέρα, και ο δέκτης κάνει την κλήση στο Cloud API με το token του αριθμού. Έτσι το token δεν βρίσκεται ποτέ μέσα στο Flowise και ο κανόνας των 24 ωρών εφαρμόζεται στον κώδικα, ελέγχοντας πότε έγραψε τελευταία φορά η επαφή, αντί να αφεθεί σε ένα μοντέλο που μπορεί να τον ξεχάσει.

Τα εισερχόμενα μηνύματα φτάνουν και πάλι μόνο μέσω του webhook, όποιος κι αν είναι ο τρόπος αποστολής.

Συνηθισμένα λάθη

• Παράλειψη του sessionId. Τότε όλοι οι πελάτες μοιράζονται μία μνήμη και τα στοιχεία ενός ατόμου μπορούν να εμφανιστούν στην απάντηση σε άλλο.
• Αναμονή του Flowise πριν απαντήσετε στη Meta. Ένα αργό 200 ξαναδοκιμάζεται, με αποτέλεσμα το ίδιο μήνυμα να επεξεργάζεται δύο φορές.
• Αποστολή ελεύθερου κειμένου από το flow μία ημέρα αργότερα. Εκτός παραθύρου η Meta το απορρίπτει με το σφάλμα 131047.

Συχνές ερωτήσεις

Συνεχίστε την ανάγνωση