LINK موبلٹی نفاذ گائیڈ REST API SMS
LINK موبلٹی پیغام کی ترسیل، مائیکرو ادائیگیوں، اور مقام پر مبنی خدمات کے لیے ایک خدمت فراہم کرتی ہے۔ یہ پلیٹ فارم ایک شفاف، وائٹ لیبل مواد حاصل کرنے والے اور سروس پرووائیڈرز اور آپریٹرز کے درمیان ٹرانزیکشن روٹر کے طور پر کام کرتا ہے۔
LINK Mobility ایک RESTful API فراہم کرتا ہے جسے LINK Mobility سروسز تک رسائی حاصل کرنے کے لیے استعمال کیا جا سکتا ہے جیسے SMS بھیجنا۔ یہ API تمام جدید زبانوں اور فریم ورک کے ساتھ استعمال میں آسان اور ہم آہنگ ہونے کے لیے ڈیزائن کیا گیا ہے۔ اپنی پسند کی زبان کا استعمال کرتے ہوئے آپ کی ایپلیکیشن طاقتور پیغام رسانی اور ادائیگی کی صلاحیتوں کو نافذ کرنے کے لیے Link Mobility REST API کا استعمال کر سکتی ہے۔
© LINK موبلٹی، 10 مارچ 2021
قانونی معلومات
اس دستاویز میں فراہم کردہ معلومات Netsize کی واحد ملکیت اور کاپی رائٹ ہیں۔ یہ خفیہ ہے اور سختی سے معلوماتی استعمال کے لیے ہے۔ یہ پابند نہیں ہے اور بغیر اطلاع کے تبدیلیوں کے تابع ہو سکتا ہے۔ کسی بھی غیر مجاز انکشاف یا استعمال کو غیر قانونی سمجھا جائے گا۔
Netsize™ اور linkmobility™ فرانسیسی، EEC اور بین الاقوامی دانشورانہ املاک کے قوانین کے ذریعے محفوظ ہیں۔
نقل کردہ دیگر تمام ٹریڈ مارکس ان کے متعلقہ مالکان کی واحد ملکیت ہیں۔
یہاں موجود کسی بھی چیز کو Netsize پیٹنٹ، کاپی رائٹ، یا ٹریڈ مارک کے تحت کوئی لائسنس یا حق دینے کے طور پر نہیں سمجھا جائے گا۔
نیٹسائز
Société anonyme au capital de 5 478 070 یورو
سیج سوشل :62، ایونیو ایمیل زولا 92100 بولون – فرانس
418 712 477 RCS Nanterre
http://www.LinkMobility.com
http://www.linkmobility.com
دستاویز کا دائرہ کار
یہ دستاویز بیان کرتی ہے کہ کس طرح سروس فراہم کنندہ SMS کے لیے LINK Mobility REST API استعمال کرتا ہے۔ اس کا مقصد تکنیکی معماروں اور ڈیزائنرز کے لیے ہے جو سروس فراہم کرنے والے کی خدمات کو نافذ کرتے ہیں۔
1. بنیادی استعمال
ایس ایم ایس بھیجنا بہت آسان ہے۔ آپ LINK موبیلٹی کو ایک HTTP درخواست بھیجتے ہیں جسے صرف a کا استعمال کرکے پورا کیا جاسکتا ہے۔ web براؤزر
2. فنکشنل اوورview
لنک موبلٹی سسٹم ایس ایم ایس پیغامات کے لیے درج ذیل بنیادی فعالیت فراہم کرتا ہے:
موبائل ٹرمینیٹڈ (MT) ایس ایم ایس پیغامات بھیجنا، جیسے ٹیکسٹ یا بائنری (جیسے WAP پش) پریمیم اور معیاری شرح والے پیغامات۔
جمع کرائے گئے MT پیغامات کی ترسیل کی رپورٹیں وصول کرنا۔
موبائل اوریجنیٹڈ (MO) SMS پیغامات، پریمیم اور معیاری شرح وصول کرنا۔
SMS REST API معیاری شرح MT SMS پیغامات بھیجنے کے لیے وقف ہے۔
API تمام ایس ایم ایس پیغامات کو متضاد طور پر بھیجتا ہے، خصوصیات کو فعال کرتا ہے جیسے:
"فائر اینڈ فرجٹ" - سروس پرووائیڈر جوابی وقت کے بارے میں مزید پیش گوئی کرنا چاہتا ہے اور آپریٹر کے نتیجے کا انتظار نہیں کرنا چاہتا۔
فعالیت کی دوبارہ کوشش کریں - اگر آپریٹر کو عارضی مسائل ہوں تو LINK موبلٹی پیغام کو دوبارہ بھیجے گی۔
2.1 SMS پیغام بھیجنا
سروس فراہم کنندہ نیٹسائز کنزیومر
- MT پیغام بھیجیں۔
- واپسی پیغام ID
- ایس ایم ایس پیغام بھیجیں۔
- ترسیل کی رپورٹ فراہم کریں۔
- ترسیل کی رپورٹ بھیجیں۔
ایس ایم ایس پیغامات بھیجنے کا بنیادی بہاؤ اس طرح بیان کیا گیا ہے:
سروس پرووائیڈر LINK موبلٹی سسٹم کے ذریعے وصول کنندہ کو ایس ایم ایس پیغام بھیجنے کی درخواست کرتا ہے۔
ایک پیغام کی شناخت سروس فراہم کنندہ کو واپس کردی جاتی ہے۔ یہ ID مثال کے طور پر پیغام کو صحیح ترسیل کی رپورٹ کے ساتھ جوڑنے کے لیے استعمال کیا جا سکتا ہے۔
LINK موبلٹی روٹنگ کو سنبھالتی ہے اور مخاطب صارف کو SMS پیغام پہنچاتی ہے۔
ڈیلیوری رپورٹ کو متحرک کیا جاتا ہے، مثال کے طور پر جب SMS پیغام صارف کے آلے پر پہنچایا جاتا ہے۔
ڈیلیوری رپورٹ سروس پرووائیڈر کو بھیجی جاتی ہے۔ رپورٹ میں وہی پیغام ID ہے جو مرحلہ 2 میں واپس کیا گیا ہے۔
متبادل بہاؤ: غلط درخواست
اگر درخواست میں فراہم کردہ پیرامیٹرز یا صارف کی اسناد غلط ہیں تو سروس فراہم کرنے والے کو ایک غلطی واپس کر دی جاتی ہے۔ غلطی مسترد ہونے کی وجہ بتاتی ہے اور بہاؤ ختم ہو جاتا ہے۔ کوئی میسج آئی ڈی واپس نہیں کی جاتی۔
3. اختتامی نقطہ
ایس ایم ایس کے وسائل تک اس راستے کا استعمال کرتے ہوئے رسائی حاصل کی جاتی ہے:
/restapi/v1/sms
Example URL
https://europe.ipx.com/restapi/v1/sms
کنکشن سیکیورٹی کے لیے LINK Mobility REST API صرف HTTPS پر قابل رسائی ہے۔
لنک موبلٹی سرور سرٹیفکیٹ پر تھاوٹے سرور CA کے دستخط ہیں۔
4. آپریشنز
ایس ایم ایس سروس درج ذیل کام فراہم کرتی ہے:
| نام | راستہ |
| بھیجیں۔ | /restapi/v1/sms/send |
4.1 بھیجیں۔
بھیجنے کا عمل کسی ایک وصول کنندہ کو ایس ایم ایس بھیجنے کے لیے استعمال کیا جاتا ہے۔
یہ آپریشن بنیادی اور جدید دونوں صارفین کے لیے ہے۔ آسان ترین صورت میں، ایس ایم ایس ڈیلیور کرنے کے لیے صرف منزل کا پتہ، اور پیغام کا متن درکار ہے۔ LINK موبیلٹی ڈیٹا کوڈنگ اسکیم کا پتہ لگائے گی اور اگر ضروری ہو تو پیغام کو متعدد میسج حصوں میں خود کار طریقے سے جوڑ دے گی۔
اعلی درجے کے استعمال کے لیے، سروس فراہم کنندہ صارف ڈیٹا ہیڈر سمیت پیغام کی فارمیٹنگ کے مکمل کنٹرول کے لیے اختیاری پیرامیٹرز استعمال کر سکتا ہے۔
سروس فراہم کنندہ مربوط پیغامات بھیج سکتا ہے، لیکن صارف کے ڈیٹا اور صارف کے ڈیٹا ہیڈر کی تیاری سروس پرووائیڈر کے ذریعے کی جانی چاہیے اور LINK موبیلٹی کی طرف متعدد بھیجنے کی درخواستوں کے ذریعے پیغام بھیجا جانا چاہیے۔
5. تصدیق
HTTP بنیادی تصدیقی اسکیم کا استعمال کرتے ہوئے ہر درخواست میں صارف نام اور پاس ورڈ جمع کرایا جاتا ہے۔
https://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA
اسناد HTTP درخواست میں اجازت نامے کے ہیڈر میں بھیجی جاتی ہیں۔ کلائنٹ ہیڈر فیلڈ بناتا ہے جیسا کہ یہاں بیان کیا گیا ہے:
https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side
سابق کے لیےample، اگر صارف نام جان ہے اور changeme پاس ورڈ ہے تو نتیجے میں اختیار کا ہیڈر یہ ہے:
اجازت: بنیادی am9objpjaGFuZ2VtZSA=
فال بیک کے طور پر صارف نام اور پاس ورڈ کو درخواست کے پیرامیٹرز کے طور پر جمع کیا جا سکتا ہے۔ یہ صرف ان کلائنٹس کے لیے تجویز کیا جاتا ہے جو بنیادی تصدیق کی حمایت نہیں کرتے ہیں۔
6. درخواست جمع کروانا
6.1 استفسار کی تار
درخواست کے پیرامیٹرز کو ایک سوال کے سٹرنگ کے طور پر جمع کیا جاتا ہے جس میں نام/قدر کے جوڑے ہوتے ہیں۔ استفسار کی تار کو فیصد انکوڈنگ کا استعمال کرتے ہوئے انکوڈ کیا گیا ہے (URL انکوڈنگ)۔
http://www.w3schools.com/tags/ref_urlencode.asp
سابق کے لیےampلی، ہیلو ورلڈ! Hello+World%21 کے بطور انکوڈ کیا گیا ہے۔
6.2 لازمی درخواست کے پیرامیٹرز
| نام | زیادہ سے زیادہ لمبائی | تفصیل |
| منزل کا پتہ | 40 | MSISDN جس پر SMS پیغام بھیجا جانا چاہیے، ملک کے کوڈ سے شروع ہوتا ہے۔ سابقampلی: 46123456789۔ کچھ مارکیٹوں کے لیے (جہاں صارفین کا MSISDN مبہم ہونا ضروری ہے) یہ قدر حروف نمبری عرف بھی ہو سکتی ہے، جس کا سابقہ "#" ہے۔ |
| پیغام کا متن | 1600 | ایس ایم ایس پیغام کا مواد۔ |
6.3 اختیاری درخواست کے پیرامیٹرز (جدید استعمال کے لیے)
| نام | زیادہ سے زیادہ لمبائی | تفصیل |
| originating Address | 16 | باہر جانے والے SMS پیغام کا اصل پتہ۔ ابتدائی پتہ کی قسم originatorTON پیرامیٹر کے ذریعہ بیان کی جاتی ہے۔ مختصر نمبر کی زیادہ سے زیادہ لمبائی 16 ہے۔ الفا عددی بھیجنے والا زیادہ سے زیادہ لمبائی 11 حروف کے ساتھ GSM ڈیفالٹ الفابیٹ تک محدود ہے۔ MSISDN بھیجنے والے کی زیادہ سے زیادہ لمبائی 15 ہے (منزل ایڈریس عنصر کی طرح کی شکل کا استعمال کرتے ہوئے)۔ سسٹم کی طرف سے originatingAddress اور originatingTON کو منتخب کیے جانے پر چھوڑا جا سکتا ہے۔ یہ فنکشن مارکیٹ اور کنفیگریشن پر منحصر ہے۔ آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| بانی ٹون | 1 | اصل پتہ' نمبر کی قسم (TON): 0 - مختصر نمبر 1 – الفا عددی (زیادہ سے زیادہ لمبائی 11) 2 – MSISDN سسٹم کی طرف سے originatingAddress اور originatingTON کو منتخب کیے جانے پر چھوڑا جا سکتا ہے۔ یہ فنکشن مارکیٹ اور کنفیگریشن پر منحصر ہے۔ آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| userDataHeader | 280 | یوزر ڈیٹا ہیڈر یوزر ڈیٹا کے ساتھ مل کر 140 تک پر مشتمل ہو سکتا ہے، یعنی 280 جب ہیکس انکوڈ، آکٹٹس۔ یہ پیرامیٹر ہمیشہ ہیکس انکوڈ ہوتا ہے۔ |
| ڈی سی ایس | 3 | ڈیٹا کوڈنگ اسکیم۔ آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| پی آئی ڈی | 3 | پروٹوکول ID آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| رشتہ دار درستگی کا وقت | 6 | رشتہ دار درستگی کا وقت سیکنڈوں میں (LINK موبیلٹی کو جمع کرانے کے وقت کے نسبت)۔ زیادہ سے زیادہ قدر 604800 (7 دن) ہے اور ڈیفالٹ 48 گھنٹے ہے۔ آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| ترسیل کا وقت | 20 | ٹائمسٹamp جب ایس ایم ایس میسج ڈیلیور کیا جانا چاہیے (ڈیلیوری میں تاخیر)۔ تاریخ وقت کی شکل پر سیکشن دیکھیں۔ |
| اسٹیٹس رپورٹ کے جھنڈے | 1 | رپورٹ کی درخواست فراہم کریں: 0 - کوئی ڈیلیوری رپورٹ نہیں (پہلے سے طے شدہ) 1 - ڈیلیوری رپورٹ کی درخواست کی گئی۔ 9 - سرور ڈیلیوری رپورٹ کی درخواست کی گئی (LINK موبلٹی رپورٹ کو سروس پرووائیڈر کو آگے نہیں بھیجتی بلکہ اسے رپورٹس وغیرہ میں دستیاب کرتی ہے) |
| campaignName | 50 | LINK موبلٹی ٹرانزیکشنز ہیں۔ tagاس نام کے ساتھ ged. یہ لنک موبلٹی رپورٹس میں گروپ ٹرانزیکشنز کے لیے استعمال ہوتا ہے۔ |
| maxConcatenatedMessages | 1 | 1 اور 10 کے درمیان ایک قدر جو اس بات کی وضاحت کرتی ہے کہ کتنے مربوط پیغامات کی اجازت ہے۔ ڈیفالٹ 3 ہے۔ |
| ارتباط کی شناخت | 100 | سروس پرووائیڈر کی طرف سے فراہم کردہ ID جو ڈیلیوری رپورٹ میں گونجے گی۔ |
| صارف نام | 100 | HTTP بنیادی توثیق کے متبادل کے طور پر فراہم کی گئی ہے۔ |
| پاس ورڈ | 100 | HTTP بنیادی توثیق کے متبادل کے طور پر فراہم کی گئی ہے۔ |
6.4 HTTP درخواست کے طریقے
زیادہ سے زیادہ انٹرآپریبلٹی کے لیے، API HTTP GET اور POST درخواست کے طریقوں دونوں کو سپورٹ کرتا ہے۔ کسی دوسرے HTTP طریقوں کی اجازت نہیں ہے۔
6.4.1 حاصل کریں۔
انکوڈ شدہ استفسار سٹرنگ میں شامل کیا گیا ہے۔ URL.
حاصل کریں۔
https://europe.ipx.com/restapi/v1/sms/send?destinationAddress=461234
56789&messageText=Hello+World%21
اجازت: بنیادی am9objpjaGFuZ2VtZSA=
6.4.2 پوسٹ
انکوڈ شدہ استفسار کا سٹرنگ HTTP درخواست کے پیغام کے باڈی میں جمع کرایا جاتا ہے۔ مواد کی قسم ایپلی کیشن/x-www-form- ہےurlانکوڈ شدہ
پوسٹ https://europe.ipx.com/restapi/v1/sms/send
میزبان: europe.ipx.com
مواد کی قسم: درخواست / x-www-form-urlانکوڈ شدہ
اجازت: بنیادی am9objpjaGFuZ2VtZSA=
مواد کی لمبائی: 57
destinationAddress=46123456789&messageText=Hello+World%21
6.5 تاریخ اور وقت
تاریخ اور وقت کی نمائندگی کرنے والے REST API میں پیرامیٹرز ہمیشہ UTC ٹائم زون (Coordinated Universal Time) میں ہوتے ہیں۔ ٹائمسٹamps کو اس قطعی شکل کے ساتھ سٹرنگ کے طور پر دکھایا گیا ہے:
2017-04-25T23:20:50Z
یہ UTC میں 20 اپریل 50 کے 23 گھنٹے کے بعد 25 منٹ اور 2017 سیکنڈ کی نمائندگی کرتا ہے۔
7. جوابی پیغام
درخواست کے پیغام کو موصول کرنے اور اس کی ترجمانی کرنے کے بعد API HTTP جوابی پیغام کے ساتھ جواب دیتا ہے۔
7.1 HTTP اسٹیٹس کوڈ
REST API ہمیشہ پروسیس شدہ درخواستوں کے لیے HTTP اسٹیٹس کوڈ 200 OK واپس کرتا ہے۔ میسج باڈی میں ایک پیرامیٹر ریسپانس کوڈ ہوتا ہے جو درست نتیجہ کا تعین کرنے کے لیے استعمال ہوتا ہے۔
7.2 پیغام کا باڈی
پیغام کا باڈی JSON پر مشتمل ہوتا ہے جو درخواست کے نتائج کو بیان کرتا ہے۔
http://json.org/
Link Mobility JSON Google JSON اسٹائل گائیڈ کی تعمیل کرتا ہے۔
https://google.github.io/styleguide/jsoncstyleguide.xml
7.3 جوابی پیرامیٹرز
| نام | زیادہ سے زیادہ لمبائی | تفصیل |
| رسپانس کوڈ | 3 | 0 کامیاب لین دین کی نشاندہی کرتا ہے۔ |
| جوابی پیغام | 255 | جوابی متنی وضاحت، جیسے غلطی کا متن۔ |
| ٹائمسٹamp | 20 | تاریخ اور وقت جب LINK موبیلیٹی نے درخواست پر کارروائی کی۔ (تاریخ/وقت فارمیٹ سیکشن سے رجوع کریں)۔ |
| ٹریس آئی ڈی | 36 | لنک موبلٹی اندرونی شناخت کنندہ۔ سپورٹ اور ٹربل شوٹنگ کے لیے استعمال کیا جاتا ہے۔ |
| پیغام کی شناخت | 10 x 36 | ہر کامیاب پیغام کے لیے LINK موبلٹی منفرد میسج آئی ڈیز کی صف (ایک سے زیادہ میسج آئی ڈیز واپس کردی جاتی ہیں اگر میسج مربوط ہو)۔ ناکامی کی صورت میں چھوڑ دیا گیا۔ |
7.4 سابقampجوابات
کامیابی
HTTP/1.1 200 ٹھیک ہے۔
مواد کی قسم: درخواست/json
مواد کی لمبائی: 144
تاریخ: جمعرات، 15 ستمبر 2016 13:20:31 GMT
{"responseCode":0,"responseMessage":"کامیابی"،"ٹائمسٹamp”:”2016-09-15T13:20:31Z”, “traceId”:”f678d30879fd4adc25f2″,”messageIds”:[“1-4850879008”]}
پڑھنے کی اہلیت کے لیے یہاں وہی JSON فارمیٹ کیا گیا ہے:
{
"رسپانس کوڈ":0،
"جوابی پیغام":"کامیابی"،
"ٹائمسٹamp“:”2016-0915T13:20:31Z”,
"ٹریس آئی ڈی“:”f678d30879fd4adc25f2”,
"پیغام کی شناخت":["1-4850879008"] }
ناکامی
HTTP/1.1 200 ٹھیک ہے۔
مواد کی قسم: درخواست/json
مواد کی لمبائی: 148
تاریخ: جمعرات، 15 ستمبر 2016 13:20:31 GMT
{"responseCode":1,"responseMessage":"غلط لاگ ان یا غیر مجاز API کا استعمال","timestamp”:”2016-09-15T13:20:31Z”,”traceId”:”f678d30879fd4adc25f2″}
کامیابی
HTTP/1.1 200 ٹھیک ہے۔
مواد کی قسم: درخواست/json
مواد کی لمبائی: 144
تاریخ: جمعرات، 15 ستمبر 2016 13:20:31 GMT
{"responseCode":0,"responseMessage":"کامیابی"،"ٹائمسٹamp”:”2016-09-15T13:20:31Z”, “traceId”:”f678d30879fd4adc25f2″,”messageIds”:[“1-4850879008”]}
پڑھنے کی اہلیت کے لیے یہاں وہی JSON فارمیٹ کیا گیا ہے:
{
"رسپانس کوڈ":0،
"جوابی پیغام":"کامیابی"،
"ٹائمسٹamp“:”2016-0915T13:20:31Z”,
"ٹریس آئی ڈی“:”f678d30879fd4adc25f2”,
"پیغام کی شناخت":["1-4850879008"] }
ناکامی
HTTP/1.1 200 ٹھیک ہے۔
مواد کی قسم: درخواست/json
مواد کی لمبائی: 148
تاریخ: جمعرات، 15 ستمبر 2016 13:20:31 GMT
{"responseCode":1,"responseMessage":"غلط لاگ ان یا غیر مجاز API کا استعمال","timestamp”:”2016-09-15T13:20:31Z”,”traceId”:”f678d30879fd4adc25f2″}
7.5 رسپانس کوڈز
بھیجے گئے جواب میں درج ذیل جوابی کوڈز واپس کیے جا سکتے ہیں:
| کوڈ | متن | تفصیل |
| 0 | کامیابی | کامیابی سے عمل میں لایا گیا۔ |
| 1 | غلط لاگ ان یا غیر مجاز API کا استعمال | غلط صارف نام یا پاس ورڈ یا سروس پرووائیڈر کو LINK موبلٹی نے روک دیا ہے۔ |
| 2 | کنزیومر کو لنک موبلٹی نے بلاک کر دیا ہے۔ | کنزیومر کو LINK موبلٹی نے بلاک کر دیا ہے۔ |
| 3 | LINK موبلٹی کے ذریعہ آپریشن کا انتظام نہیں کیا گیا ہے۔ | سروس پرووائیڈر کے لیے آپریشن مسدود ہے۔ |
| 4 | صارف LINK Mobility سے ناواقف ہے۔ | صارف LINK موبلٹی سے ناواقف ہے۔ یا اگر درخواست میں عرف استعمال کیا گیا ہو؛ عرف نہیں ملا |
| 5 | صارف نے اس سروس کو LINK Mobility میں بلاک کر دیا ہے۔ | صارف نے اس سروس کو LINK Mobility میں بلاک کر دیا ہے۔ |
| 6 | اصل پتہ تعاون یافتہ نہیں ہے۔ | اصل پتہ تعاون یافتہ نہیں ہے۔ |
| 7 | الفا اصل پتہ اکاؤنٹ کے ذریعہ تعاون یافتہ نہیں ہے۔ | الفا سے نکلنے والا پتہ اکاؤنٹ کے ذریعے تعاون یافتہ نہیں ہے۔ |
| 8 | MSISDN ابتدائی پتہ تعاون یافتہ نہیں ہے۔ | MSISDN شروع کرنے والا پتہ تعاون یافتہ نہیں ہے۔ |
| 9 | GSM توسیع شدہ تعاون یافتہ نہیں ہے۔ | GSM توسیع شدہ تعاون یافتہ نہیں ہے۔ |
| 10 | یونیکوڈ تعاون یافتہ نہیں ہے۔ | یونیکوڈ تعاون یافتہ نہیں ہے۔ |
| 11 | اسٹیٹس رپورٹ تعاون یافتہ نہیں ہے۔ | اسٹیٹس رپورٹ تعاون یافتہ نہیں ہے۔ |
| 12 | مطلوبہ صلاحیت تعاون یافتہ نہیں ہے۔ | پیغام بھیجنے کے لیے مطلوبہ صلاحیت (اوپر کے علاوہ) تعاون یافتہ نہیں ہے۔ |
| 13 | مواد فراہم کرنے والے کی زیادہ سے زیادہ تھروٹلنگ کی شرح سے تجاوز کر گیا ہے۔ | سروس پرووائیڈر LINK موبیلٹی کو ایس ایم ایس پیغامات بہت تیزی سے بھیج رہا ہے۔ |
| 14 | پروٹوکول ID اکاؤنٹ کے ذریعہ تعاون یافتہ نہیں ہے۔ | پروٹوکول ID تعاون یافتہ نہیں ہے۔ |
| 15 | میسج کنیکٹنیشن کی حد سے تجاوز کر گیا۔ | مربوط پیغامات کی تعداد درخواست کردہ زیادہ سے زیادہ تعداد سے زیادہ ہے۔ |
| 16 | پیغام کو روٹ کرنے سے قاصر۔ | LINK موبلٹی پیغام کو روٹ کرنے سے قاصر تھی۔ |
| 17 | ممنوعہ مدت | مدت کے دوران پیغام بھیجنے کی اجازت نہیں ہے۔ |
| 18 | سروس فراہم کنندہ کے اکاؤنٹ پر بہت کم بیلنس | بہت کم بیلنس کی وجہ سے سروس فراہم کرنے والے کو بلاک کر دیا گیا ہے۔ |
| 50 | جزوی کامیابی | ایک سے زیادہ وصول کنندگان کو SMS پیغام بھیجنے پر جزوی کامیابی۔ |
| 99 | اندرونی سرور کی خرابی۔ | دیگر لنک موبلٹی کی خرابی، مزید معلومات کے لیے LINK موبلٹی سپورٹ سے رابطہ کریں۔ |
| 100 | غلط منزل کا پتہ | منزل کا پتہ (MSISDN، یا عرف) غلط ہے۔ |
| 102 | غلط حوالہ شدہ (منسلک) ID | حوالہ ID غلط ہے، ہو سکتا ہے حوالہ ID پہلے سے استعمال ہو، بہت پرانی یا نامعلوم۔ |
| 103 | اکاؤنٹ کا نام غلط ہے۔ | اکاؤنٹ کا نام غلط ہے۔ |
| 105 | غلط سروس میٹا ڈیٹا | سروس میٹا ڈیٹا غلط ہے۔ |
| 106 | غلط اصل پتہ | اصل پتہ غلط ہے۔ |
| 107 | غلط حروف نمبری ابتدائی پتہ | حروف عددی ابتدائی پتہ غلط ہے۔ |
| 108 | غلط درستگی کا وقت | درستگی کا وقت غلط ہے۔ |
| 109 | غلط ترسیل کا وقت | ترسیل کا وقت غلط ہے۔ |
| 110 | غلط پیغام کا مواد/صارف کا ڈیٹا | صارف کا ڈیٹا، یعنی SMS پیغام، غلط ہے۔ |
| 111 | غلط پیغام کی لمبائی | SMS پیغام کی لمبائی غلط ہے۔ |
| 112 | غلط صارف ڈیٹا ہیڈر | صارف کا ڈیٹا ہیڈر غلط ہے۔ |
| 113 | غلط ڈیٹا کوڈنگ سکیم | DCS غلط ہے۔ |
| 114 | غلط پروٹوکول ID | PID غلط ہے۔ |
| 115 | غلط اسٹیٹس رپورٹ کے جھنڈے | اسٹیٹس رپورٹ کے جھنڈے غلط ہیں۔ |
| 116 | غلط TON | ابتدا کرنے والا TON غلط ہے۔ |
| 117 | غلط جampaign نام | سیampaign نام غلط ہے۔ |
| 120 | مربوط پیغامات کی زیادہ سے زیادہ تعداد کے لیے غلط حد | مربوط پیغامات کی زیادہ سے زیادہ تعداد غلط ہے۔ |
| 121 | غلط msisdn شروع کرنے والا پتہ | MSISDN شروع کرنے والا پتہ غلط ہے۔ |
| 122 | غلط ارتباط ID | ارتباط ID غلط ہے۔ |
8. اختیاری خصوصیات
8.1 MSISDN تصحیح
MSISDN اصلاح ایک اختیاری خصوصیت ہے جسے اگر درخواست کی جائے تو LINK موبلٹی سپورٹ کے ذریعے فعال کیا جا سکتا ہے۔
یہ فیچر منزل کے پتوں کو درست کرے گا اور انہیں مطلوبہ E.164 فارمیٹ کے مطابق ترتیب دے گا۔ فارمیٹ کی اصلاح کے علاوہ یہ نظام مارکیٹ کی مخصوص فعالیت بھی انجام دے سکتا ہے جیسے کہ بین الاقوامی فرانسیسی نمبروں کا ترجمہ DOM-TOM (départements et territoires d'outre-mer) نمبروں کو درست کرنے کے لیے جب قابل اطلاق ہو۔
ذیل میں متعدد سابق ہیں۔ampتصحیحات:
| جمع کرائی گئی منزل کا پتہ | درست شدہ منزل کا پتہ |
| +46(0)702233445 | 46702233445 |
| (0046)72233445 | 46702233445 |
| +460702233445 | 46702233445 |
| 46(0)702233445 | 46702233445 |
| 46070-2233445 | 46702233445 |
| 0046702233445 | 46702233445 |
| +46(0)702233445aaa | 46702233445 |
| 336005199999 | 2626005199999 (فرانسیسی نمبر کا ترجمہ DOM-TOM نمبر میں) |
مزید برآں، منتخب مارکیٹ کے لیے قومی فون نمبرز کی اجازت دینا ممکن ہے۔ جب اس خصوصیت کو فعال کیا جاتا ہے تو دیگر مارکیٹوں کے لیے کسی بھی بین الاقوامی نمبر کو ابتدائی `+' نشان کے ساتھ بھیجنا چاہیے تاکہ انہیں منتخب مارکیٹ سے ممتاز کیا جا سکے۔
ذیل میں کئی سابق ہیں۔ampسویڈن (ملکی کوڈ 46) کو قومی نمبروں کے لیے ڈیفالٹ مارکیٹ کے طور پر استعمال کرتے وقت کی گئی اصلاحات۔
| جمع کرائی گئی منزل کا پتہ | درست شدہ منزل کا پتہ |
| 0702233445 | 46702233445 |
| 070-2233 445 | 46702233445 |
| 070.2233.4455 | 46702233445 |
| 460702233445 | 46702233445 |
| +460702233445 | 46702233445 |
| +458022334455 | 458022334455 |
| 45802233445 | غلط ہے کیونکہ '+' نشان غائب ہے۔ |
نوٹ کریں کہ درست کیا گیا MSISDN LINK Mobility کے ذریعے استعمال کیا جائے گا اور اسے ڈیلیوری رپورٹس میں واپس کر دیا جائے گا۔
مزید معلومات کے لیے براہ کرم LINK موبلٹی سپورٹ سے رابطہ کریں۔
8.2 کردار کی تبدیلی
کردار کی تبدیلی ایک اختیاری خصوصیت ہے جسے اگر درخواست کی جائے تو LINK موبلٹی سپورٹ کے ذریعے فعال کیا جا سکتا ہے۔
یہ فیچر صارف کے ڈیٹا (SMS ٹیکسٹ) میں غیر GSM حروف تہجی کے حروف کو GSM حروف تہجی کے مساوی حروف میں ترجمہ کرے گا جب DCS "GSM" (17) پر سیٹ ہو گا۔ سابق کے لیےample "Seqüência de teste em Português" کا ترجمہ "Seqüencia de teste em Portugues" میں کیا جائے گا۔
9. ڈیلیوری رپورٹس
سروس فراہم کرنے والا، اگر فراہم کیا گیا ہو، بھیجے گئے MT پیغامات کے لیے SMS پیغام کی ترسیل کی رپورٹس یا ترسیل کی اطلاعات کی درخواست کر سکتا ہے۔ یہ رپورٹس آپریٹر SMSC میں اس وقت متحرک ہوتی ہیں جب MT پیغام یا تو ہدف شدہ صارف کو پہنچایا جاتا ہے یا حذف کر دیا جاتا ہے، مثلاً، میعاد ختم ہو چکی ہے یا، کسی وجہ سے، روٹیبل نہیں ہے۔
سروس پرووائیڈر کو ایس ایم ایس میسج کی صرف حتمی حیثیت کی اطلاع دی جاتی ہے، یعنی ڈیلیور یا ڈیلیٹ کیا جاتا ہے۔ فی MT پیغام صرف ایک رپورٹ تیار ہوتی ہے۔ حذف شدہ حیثیت کے ساتھ، ایک وجہ کوڈ لاگو ہو سکتا ہے۔ یہ وجہ کوڈ ایس ایم ایس پیغام کے ڈیلیور نہ ہونے کی وجہ بتاتا ہے۔
رپورٹس کو LINK موبلٹی کے ذریعے روٹ کیا جاتا ہے اور HTTP پروٹوکول کا استعمال کرتے ہوئے سروس پرووائیڈر کو بھیجا جاتا ہے۔
رپورٹس حاصل کرنے کے لیے، سروس پرووائیڈر کو سابق کے لیے لاگو کرنے کی ضرورت ہے۔ampجاوا سرولیٹ یا ASP.NET صفحہ۔ دونوں کو HTTP GET یا POST کی درخواستیں موصول ہوتی ہیں۔
پیرامیٹرز
درخواست میں درج ذیل پیرامیٹرز شامل ہیں:
| پیرامیٹر | قسم | M/O/I* | ڈیفالٹ قدر | زیادہ سے زیادہ لمبائی | تفصیل |
| میسج آئی ڈی | تار | M | - | 22 | MT پیغام کی میسج ID جس سے یہ رپورٹ مماثل ہے۔ |
| منزل کا پتہ | تار | M | - | 40 | صارفین کا MSISDN، یعنی اصل MT پیغام کی منزل کا پتہ۔ |
| اسٹیٹس کوڈ | عدد | M | 1 | اسٹیٹس کوڈ ایم ٹی پیغام کی حیثیت کی نشاندہی کرتا ہے۔ قابل اطلاق اسٹیٹس کوڈز ہیں: 0 - ڈیلیور کیا گیا۔ 2 - حذف شدہ (وجہ کوڈ لاگو ہوتا ہے) |
|
| ٹائم سٹamp | تار | M | - | 20 | وقت بتاتا ہے جب LINK موبلٹی کو ڈیلیوری رپورٹ موصول ہوئی تھی۔ ٹائم زون کا ٹائم زونamp CET یا CEST ہے (گرمیوں کے وقت کے ساتھ جیسا کہ EU کے لیے بیان کیا گیا ہے)۔ فارمیٹ: yyyyMMdd HH:mm:ss۔ |
| آپریٹر | تار | M | - | 100 | ایس ایم ایس پیغام بھیجتے وقت استعمال ہونے والے آپریٹر کا نام یا ایس ایم ایس پیغام بھیجتے وقت استعمال ہونے والا اکاؤنٹ کا نام۔ دستیاب آپریٹرز کی فہرست LINK موبلٹی سپورٹ کے ذریعے فراہم کی گئی ہے۔ |
| ریزن کوڈ | عدد | O | - | 3 | وجہ کوڈ اس بات کی نشاندہی کرتا ہے کہ پیغام حذف شدہ حیثیت میں کیوں ختم ہوا۔ قابل اطلاق وجہ کوڈ ہیں: 100 - میعاد ختم 101 - مسترد 102 - فارمیٹ کی خرابی۔ 103 - دوسری غلطی 110 - سبسکرائبر نامعلوم 111 - سبسکرائبر پر پابندی لگا دی گئی۔ 112 - سبسکرائبر کا انتظام نہیں کیا گیا۔ 113 - سبسکرائبر دستیاب نہیں ہے۔ 120 - SMSC ناکامی۔ 121 - ایس ایم ایس سی بھیڑ 122 - SMSC رومنگ 130 - ہینڈ سیٹ کی خرابی۔ 131 - ہینڈ سیٹ میموری کی حد سے تجاوز کر گئی۔ آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| OperatorTimeStamp | تار | O | - | 20 | وقت بتاتا ہے کہ آپریٹر کے ایس ایم ایس سی میں رپورٹ کب شروع کی گئی تھی (اگر آپریٹر نے فراہم کی ہو)۔ ٹائم زون کا ٹائم زونamp CET یا CEST ہے (گرمیوں کے وقت کے ساتھ جیسا کہ EU کے لیے بیان کیا گیا ہے)۔ فارمیٹ: yyyyMMdd HH:mm:ss۔ |
| اسٹیٹس ٹیکسٹ | تار | O | - | 255 | آپریٹر کی جانب سے اضافی معلومات کے لیے پلیس ہولڈر، مثلاً اسٹیٹس/وجہ کی واضح متن کی وضاحت۔ آپریٹر کے انضمام کے ساتھ رویہ مختلف ہو سکتا ہے۔ |
| ارتباط کی شناخت | تار | O | - | 100 | SendRequest یا SendTextRequest میں فراہم کردہ ارتباطی ID۔ |
| آپریٹر نیٹ ورک کوڈ | عدد | O | - | 6 | آپریٹر کا موبائل نیٹ ورک کوڈ (MCC + MNC)۔ |
* M = لازمی، O = اختیاری، I = نظر انداز۔
سروس پرووائیڈر کو ٹارگٹ کے ساتھ LINK موبیلٹی فراہم کرنی ہوگی۔ URL ڈیلیوری رپورٹس کے لیے (اختیاری طور پر HTTP بنیادی تصدیق کے لیے اسناد سمیت)۔ سروس فراہم کنندہ منتخب کر سکتا ہے کہ کون سا ترجیحی HTTP طریقہ استعمال کرنا ہے:
HTTP پوسٹ (تجویز کردہ)
HTTP حاصل کریں۔
Example HTTP GET کا استعمال کرتے ہوئے (کامیابی سے پہنچایا گیا):
https://user:password@www.serviceprovider.com/receivereport?%20MessageId=122&DestinationAddress=46762050312&Operator=Vodafone&TimeStamp=20100401%2007%3A47%3A44&StatusCode=0
Example HTTP GET کا استعمال کرتے ہوئے (ڈیلیور نہیں کیا گیا، آپریٹر نے ٹائمسٹ سپلائی کیا ہے۔amp تقریب کے لیے):
پیرامیٹرز ہیں۔ URL انکوڈی
کریکٹر انکوڈنگ:
سروس فراہم کنندہ منتخب کر سکتا ہے کہ کون سا ترجیحی کریکٹر انکوڈنگ استعمال کرنا ہے:
UTF-8 (تجویز کردہ)
ISO-8859-1۔
9.1 سروس فراہم کنندہ کا اعتراف
سروس پرووائیڈر کو ہر ڈیلیوری رپورٹ کو تسلیم کرنا چاہیے۔ اعتراف مثبت ہو سکتا ہے، یعنی ڈیلیوری رپورٹ کامیابی سے موصول ہوئی، یا منفی، یعنی ناکامی۔
براہ کرم نوٹ کریں: LINK موبلٹی کے پاس ڈیلیوری رپورٹس کے لیے 30 سیکنڈ کے اعترافات کے پڑھنے کا ٹائم آؤٹ ہے۔ ٹائم آؤٹ ڈیلیوری کی دوبارہ کوشش کو متحرک کرے گا (اگر دوبارہ کوشش کی گئی ہو) یا ڈیلیوری کی منسوخی (اگر دوبارہ کوشش غیر فعال ہو)۔ اس کا مطلب ہے کہ سروس پرووائیڈر ایپلیکیشن کو فوری ردعمل کے اوقات کو یقینی بنانا چاہیے، خاص طور پر زیادہ بوجھ کے دوران۔
اس پر کارروائی کرنے سے پہلے LINK موبیلٹی کی طرف ڈیلیوری رپورٹ کو تسلیم کرنے کی انتہائی سفارش کی جاتی ہے۔
مثبت اور منفی اقرار کا اصول یوں بیان کیا گیا ہے:
مثبت اعتراف، ACK، ڈیلیوری رپورٹ پیش کی گئی:
HTTP 200 رینج رسپانس کوڈ درج ذیل XML فارمیٹ شدہ مواد کے ساتھ مل کر:
منفی اعتراف، NAK، ترسیل کی رپورٹ فراہم نہیں کی گئی:
مثبت اعتراف کے علاوہ کوئی بھی جواب، مثال کے طور پرample، ایک منفی اعتراف کسی بھی HTTP ایرر کوڈ یا درج ذیل XML مواد سے شروع ہوتا ہے۔
XML مواد کو LINK موبلٹی کی دوبارہ کوشش کے طریقہ کار کو کنٹرول کرنے کے لیے استعمال کیا جا سکتا ہے۔ NAK دوبارہ کوشش کرنے کا سبب بنے گا، اگر فعال کیا گیا ہے۔ دوبارہ کوشش کرنے کے طریقہ کار کے لیے کنفیگر نہ کیے گئے سروس فراہم کنندگان کے لیے، XML مواد اختیاری ہے۔
ذیل میں ایک HTTP POST درخواست اور جواب سابق ہے۔ampسروس پرووائیڈر کو ڈیلیوری رپورٹ کی لی:
HTTP درخواست:
POST/context/app HTTP/1.1
مواد کی قسم: درخواست / x-www-form-urlencoded;charset=utf-8
میزبان: سرور: پورٹ
مواد کی لمبائی: xx
MessageId=213123213&DestinationAddress=46762050312&Operator=Telia& OperatorTimeStamp=20130607%2010%3A45%3A00&TimeStamp=20130607%2010%3A 45%3A02&StatusCode=0
HTTP جواب:
HTTP/1.1 200 ٹھیک ہے۔
مواد کی قسم: متن/سادہ
9.2 دوبارہ کوشش کریں۔
LINK موبلٹی سسٹم ناکام، یعنی تسلیم شدہ نہیں، ڈیلیوری رپورٹ کی ترسیل کے لیے دوبارہ کوشش کر سکتا ہے۔ سروس فراہم کنندہ ترجیحی دوبارہ کوشش کرنے کے طرز عمل کا انتخاب کر سکتا ہے:
دوبارہ کوشش نہیں (پہلے سے طے شدہ) - اگر کنکشن کی کوشش ناکام ہو جاتی ہے، ٹائم آؤٹ پڑھیں یا کسی HTTP ایرر کوڈ کے لیے پیغام کو رد کر دیا جائے گا۔
دوبارہ کوشش کریں۔ - پیغام ہر قسم کے کنکشن کے مسئلے، پڑھنے کا ٹائم آؤٹ، یا منفی اعتراف کے لیے دوبارہ بھیجا جائے گا۔
جب NAK کے لیے دوبارہ کوشش کو فعال کیا جاتا ہے، تو یہ سمجھنا ضروری ہے کہ کون سے منظرنامے جو LINK Mobility سے دوبارہ کوشش کرنے کی کوشش پیدا کریں گے اور دوبارہ کوشش کیسے کام کرتی ہے۔ ہر سروس پرووائیڈر کی اپنی دوبارہ کوشش کی قطار ہوتی ہے، جہاں پیغامات کو میسج ٹائمسٹ کے مطابق آرڈر کیا جاتا ہے۔amp. Link Mobility ہمیشہ پرانے پیغامات کو پہلے پہنچانے کی کوشش کرتی ہے، حالانکہ سروس پرووائیڈر کو بھیجے گئے پیغامات کے انفرادی آرڈر کی ضمانت نہیں ہے۔ پیغامات کو دوبارہ کوشش کی قطار سے خارج کرنے کی بنیادی وجہ دو وجوہات میں سے ایک ہے: یا تو پیغام TTL کی میعاد ختم ہو جاتی ہے یا (نظریاتی طور پر) دوبارہ کوشش کی قطار بھر جاتی ہے۔ TTL آپریٹر ہے اور اکاؤنٹ پر منحصر ہے، یعنی آپریٹر اور یا پیغام کی قسم، جیسے پریمیم ایس ایم ایس یا معیاری ریٹ ایس ایم ایس پیغام کے لحاظ سے مختلف ہو سکتے ہیں۔
دوبارہ کوشش کرنے والے سروس پرووائیڈرز کو MT پیغام کی منفرد ID چیک کرنی چاہیے تاکہ یہ محفوظ ہو سکے کہ پیغام پہلے ہی موصول نہیں ہوا ہے۔
سروس پرووائیڈر کے لیے ان آسان اصولوں کی تعمیل کرنا ضروری ہے جب ڈیلیوری رپورٹ کی پروسیسنگ کے دوران کوئی خرابی پیش آتی ہے اگر خرابی کی وجہ یہ ہے: عارضی، مثلاً ڈیٹا بیس دستیاب نہیں، NAK واپس کیا جانا چاہیے۔ LINK موبلٹی پیغام کو دوبارہ بھیجے گی۔
مستقل اور دوبارہ کوشش کرنے سے ایک ہی قسم کا مسئلہ پیدا ہونے کا امکان ہے، ACK کو واپس کیا جانا چاہیے۔ سابق کے لیےample، جب پیغام کو صحیح طریقے سے پارس نہیں کیا جا سکا یا رن ٹائم میں غیر متوقع خرابی پیدا ہو گئی۔
اس کے مطابق عمل کرنا اس بات کو یقینی بنائے گا کہ ڈیلیوری رپورٹ بار بار بھیجے جانے کی وجہ سے کوئی بلاکنگ یا تھرو پٹ انحطاط نہ ہو۔
10. نفاذ کی تجاویز
1. آپ کا استعمال کرنا ممکن ہے۔ web API کو درخواستیں جمع کرانے کے لیے براؤزر۔ یہ بغیر کسی ترقیاتی ٹولز کے خدمات کو دریافت کرنا اور ان کا جائزہ لینا بہت آسان بناتا ہے۔
2. کروم یا فائر فاکس کی سفارش JSON جیسی ایکسٹینشن کے ساتھ کی جاتی ہے۔View خوبصورت فارمیٹ شدہ JSON کو ظاہر کرنے کے لیے۔
3. ہم نے POST، بنیادی تصدیق کی جانچ اور خام HTTP درخواست اور جوابی پیغامات کی جانچ کے لیے SoapUI کا استعمال کیا ہے۔
4. سیURL ٹول بنیادی تصدیق کے ساتھ POST درخواستیں جمع کرانے کے لیے مفید ہے۔ سابق دیکھیںampذیل میں.
curl پوسٹ \
-H "مواد کی قسم: درخواست/x-www-form-urlانکوڈ شدہ"\
-H "اختیار: بنیادی am9objpjaGFuZ2VtZSA=" \
https://europe.ipx.com/restapi/v1/sms/send \
-ڈیٹا "منزل کا پتہ=46123456789&messageText=Hello+World%21"
_______________
ذاتی مواصلات کو تبدیل کرنا
دستاویزات / وسائل
 |
LINK موبلٹی نفاذ گائیڈ REST API SMS [پی ڈی ایف] یوزر گائیڈ موبلٹی امپلیمینٹیشن گائیڈ REST API SMS, Mobility, Implementation Guide REST API SMS, REST API SMS, API SMS, SMS |
