შეტყობინებების ბრენდის განახლება

არსებული შეტყობინებების ბრენდის მონაცემების შესწორება

განაახლეთ არსებული ბრენდი, როდესაც ბიზნესის საკონტაქტო მონაცემები ან მისამართი იცვლება. შეინარჩუნეთ ბრენდის იდენტიფიკატორი; სხვა რეგისტრაციის შექმნა არსებული ბიზნესის მონაცემების შესწორების გზა არ არის. გამოიყენეთ ჩართული API ანგარიში HTTPS კავშირით, ნებადართული საწყისი IP მისამართიდან. ბრენდი ამ ანგარიშს უნდა ეკუთვნოდეს.

დაიწყეთ მიმდინარე ჩანაწერის წაკითხვით. ადგილობრივი ასლი კონფიდენციალურად შეინახეთ, რადგან ის ბიზნესის საიდენტიფიკაციო და საკონტაქტო ინფორმაციას შეიცავს.

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
  --output current-brand.json

შეინარჩუნეთ ბრენდის მიმდინარე ველები

მიმდინარე ჩანაწერიდან მოამზადეთ brand-update.json და აირჩიეთ მხოლოდ ბრენდის ჩაწერისთვის ხელმისაწვდომი ველები. სასურველი შესწორების შეტანისას შეინარჩუნეთ ბიზნესის საიდენტიფიკაციო მონაცემები და სხვა სავალდებულო მნიშვნელობები. არ გაგზავნოთ GET მოთხოვნის სრული პასუხი: brandId, იდენტობისა და სტატუსის შედეგები, დროის ნიშნულები და მხოლოდ პასუხისთვის განკუთვნილი სხვა ველები განახლებაში არ უნდა შედიოდეს.

განახლების სქემა მოითხოვს შემდეგ ველებს: entityType, displayName, country, email და brandRelationship. სუბიექტის ტიპისთვის სპეციფიკური წესები კვლავ მოქმედებს. ორგანიზაციის შემთხვევაში, საჭიროებისამებრ შეინარჩუნეთ კომპანიის იურიდიული სახელწოდება, საგადასახადო იდენტიფიკატორი და მისი გამცემი ქვეყანა, მისამართი და საქმიანობის დარგი. ინდივიდუალური მეწარმის შემთხვევაში კი შეინარჩუნეთ პირის სახელისა და მობილური საკონტაქტო მონაცემების შესაბამისი ველები. გამოიყენეთ რეალური მიმდინარე მნიშვნელობები და არა რეგისტრაციის მაგალითში მოცემული ჩანაცვლების ტექსტები.

ბრენდის განახლების ველების ჯგუფები
ველები	გამოყენების წესი
displayName, email, phone	ბრენდის ადვილად ამოსაცნობი სახელი და მოქმედი საკონტაქტო მონაცემები. მაქსიმალური სიგრძეებია: 255, 100 და 20 სიმბოლო. ტელეფონის ნომერი მიუთითეთ საერთაშორისო ფორმატით, + ნიშნითა და ქვეყნის კოდით.
street, city, state, postalCode, country	ბიზნესის რეალური მისამართი ურთიერთშეთანხმებული მონაცემებით. სიგრძის ლიმიტებია: 255, 100, 20, 10 და 2 სიმბოლო. შესაბამის შემთხვევებში გამოიყენეთ აშშ-ის შტატების მოქმედი კოდები.
entityType, companyName, ein, einIssuingCountry	იურიდიული საიდენტიფიკაციო მონაცემები. მათი ცვლილება შეზღუდულია, როდესაც კამპანიები ან გარე შემოწმება მოლოდინის რეჟიმშია ან აქტიურია. არ წაშალოთ მოქმედი კამპანიები მხოლოდ საიდენტიფიკაციო მონაცემებზე დაწესებული შეზღუდვის გვერდის ასავლელად.
firstName, lastName, mobilePhone, businessContactEmail	საიდენტიფიკაციო მონაცემები ან დადასტურებისთვის საჭირო საკონტაქტო მონაცემები, თუ ეს სუბიექტის ტიპს შეესაბამება. სიგრძის ლიმიტებია: 100, 100, 20 და 255 სიმბოლო.
brandRelationship, vertical	ურთიერთობისა და საქმიანობის დარგის მიმდინარე კოდები. ურთიერთობის შეცვლა დასაშვებია მხოლოდ სამ თვეში ერთხელ. პორტალის ჩვეულებრივი რედაქტირების ფორმა ურთიერთობის შეცვლის შესაძლებლობას არ იძლევა.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	შესაბამისი ვებსაიტი, ბიზნესის ალტერნატიული საიდენტიფიკაციო მონაცემები და საჯარო კომპანიის მონაცემები. შეინარჩუნეთ სუბიექტის ვალიდაციისთვის საჭირო მნიშვნელობები.
referenceId, ipAddress	ბიზნესის მითითებისა და საწყისი IP მისამართის მხარდაჭერილი მეტამონაცემები. არცერთი მათგანი არ განსაზღვრავს ანგარიშის მფლობელობას და არც მოთხოვნის იდემპოტენტურობის გასაღების ფუნქციას ასრულებს.

კოდებისთვის გამოიყენეთ მიმდინარე შეტყობინებების კატალოგები. განახლების სქემაში mock ბრენდის გარემოს შეცვლის საშუალებად არ არის ხელმისაწვდომი. რედაქტირებისას ამ ალმის შეცვლის ნაცვლად გამოიყენეთ სატესტო გარემოდან საწარმოო გარემოში გადასვლის ცალკე, განხილული პროცესი.

გაგზავნეთ განხილული შესწორება

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @brand-update.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID"

ამ დაგეგმილი განახლებისთვის გამოიყენეთ ერთი გასაღები და შეინახეთ მოთხოვნის სხეულის ზუსტი ბაიტები. შეცვლილი მეთოდით, გზით, მოთხოვნის პარამეტრებით ან სხეულით იმავე გასაღების ხელახლა გამოყენება კონფლიქტს იწვევს; JSON ფორმატირების შეცვლაც ცვლის ანაბეჭდს. უკვე დამუშავების პროცესში მყოფი მოთხოვნის დუბლიკატმა შეიძლება დააბრუნოს 409 და Retry-After. დასრულებულმა მოთხოვნამ შეიძლება ხელახლა დააბრუნოს შენახული შედეგი, მათ შორის შეცდომაც. ლოდინის დროის ამოწურვის შემდეგ შედეგის გარკვევისას შეინახეთ მოთხოვნის დეტალები, ნაცვლად ახალი გასაღების ავტომატურად შექმნისა.

შეამოწმეთ შენახული ჩანაწერი და ვალიდაციის მდგომარეობა

წარმატებული განახლება აბრუნებს HTTP 200 სტატუსს და უშუალოდ ბრენდის JSON ობიექტს, ძველი v3 ვერსიის status/response გარსის გარეშე. შეამოწმეთ მისი brandId, შემდეგ GET მოთხოვნით ხელახლა წაიკითხეთ იგივე ბრენდი და შეადარეთ შესაცვლელად განსაზღვრული ველები. განახლების საჯარო მარშრუტი არ იღებს პორტალის changes/version გარსს და არ უზრუნველყოფს მის ოპტიმისტურ ერთდროულობის შემოწმებას. შეათანხმეთ ერთდროულად მომუშავე რედაქტორების მოქმედებები; იდემპოტენტურობის გასაღები ხელს უშლის განმეორებით გაგზავნას, მაგრამ ვერ აღკვეთს სხვა რედაქტორის ცვლილებებს.

მიმდინარე პორტალი კითხულობს ბრენდს, ინარჩუნებს მის ჩაწერისთვის ხელმისაწვდომ ველებს, შენახვამდე ამოწმებს ფორმის ვერსიას და შედეგს ხელახლა კითხულობს. აქტიური კამპანიების აღმოჩენისას ის ბლოკავს ძირითად იურიდიულ საიდენტიფიკაციო ველებს. რეესტრს შეუძლია დააწესოს დამატებითი შეზღუდვები, მათ შორის გარე შემოწმებასთან დაკავშირებული შეზღუდვები, მაშინაც კი, თუ ველი ფორმაში ხელმისაწვდომი იყო.

შესწორებული ინფორმაციის შენახვა ავტომატურად არ ითხოვს იდენტობის ხელახალ დადასტურებას და არც დამტკიცების გარანტიას იძლევა. ხელახალი დადასტურება ცალკე მოქმედებაა და შეიძლება ფასიანი იყოს; პორტალში შეამოწმეთ მიმდინარე მდგომარეობა და აშკარად დაადასტურეთ ნებისმიერი მითითებული გადასახადი. მიმდინარე API სერვისში ბრენდის ჩვეულებრივი PUT განახლებები რეგისტრაციის ცალკე საფასურის ჩამოჭრას არ იწვევს. კამპანიების, შეტყობინებებისა და სხვა არსებული გადასახადები ცალკე რჩება.

მოაგვარეთ შეცდომები დუბლიკატის რეგისტრაციის გარეშე

წაიკითხეთ HTTP სტატუსი და შეცდომის დეტალები JSON ფორმატში. 400-ის შემთხვევაში შეასწორეთ კონკრეტული ველი ან დაიცავით საიდენტიფიკაციო მონაცემებსა თუ ურთიერთობაზე დაწესებული შეზღუდვა. 401, 403 ან 404-ის შემთხვევაში შეამოწმეთ ავტორიზაციის მონაცემები, ნებადართული საწყისი IP მისამართი და ანგარიშის მფლობელობა. 429-ის შემთხვევაში დაიცავით Retry-After მითითება. 500 ან 502 შეიძლება დაბრუნდეს მას შემდეგაც, რაც რეესტრმა განახლება მიიღო; შეინახეთ ნებისმიერი მიღებული requestId და ხელახლა გაგზავნამდე წაიკითხეთ არსებული ჩანაწერი.

განახლების არაცარიელმა, მაგრამ არასრულმა პასუხმა შეიძლება დატოვოს არასრული ადგილობრივი ასლი; წარმატებული პასუხის ცარიელი სხეულის შემთხვევაში კი შეიძლება შენარჩუნდეს ასლის ძველი ველები. მხოლოდ წარმატების სტატუსის საფუძველზე ნუ დაასკვნით, რომ ველები შენარჩუნდა. ხელახლა წაიკითხეთ ბრენდის სრული ჩანაწერი და ნებისმიერი შეუსაბამობა მხარდაჭერის სამსახურის დახმარებით მოაგვარეთ. ეს სახელმძღვანელო არ იძლევა გარანტიას, რომ რეესტრის, ადგილობრივი ქეშისა და ბილინგის განახლებები ატომურად შესრულდება.