CRM Şablonu XML Açıklaması

Giriş

Bu belge, CRM entegrasyonu için kullanılan XML şablonunun biçimini açıklar ve ayrıca motorun şablonda tanımlanan ayarlara göre nasıl çalıştığına dair bir açıklama sağlar. Son olarak, bir şablonu nasıl kolayca hata ayıklayabileceğimizi açıklıyoruz.

XML Şablon Formatı

<Crm> XML şablonunun kök öğesidir ve şunları içerir:

• Name (string) - Şablonun adı. Kullanıcıya CRM'i tanımlamak için gösterilir.
• Version (integer) - Güncellemeler için şablon versiyonu.
• Country (string) - Şablonun geçerli olduğu ülke, şu anda kullanılmıyor, ancak zorunlu bir özelliktir.
• SupportsEmojis (boolean) - Sohbet konuşmasını CRM'de saklarken CRM'nin emojileri destekleyip desteklemediğini belirtir. Bu yanlışsa, emojiler CRM'e gönderilmeden önce sohbet mesajlarından kaldırılır. Öznitelik belirtilmezse varsayılan "false" değeri kullanılır.

<Crm> öğesi aşağıdaki alt öğeleri içerir:

• Number
• Connection
• Parameters
• Authentication
• Scenarios

Numara Elemanı

Bu öğe, alınan arayan numarasını CRM'in beklediği şekilde biçimlendirmek için kullanılır. Ortaya çıkan numara, kişi eşleştirmesi için kullanılacaktır. Aşağıdaki niteliklere sahiptir:

Prefix (Enum) - arayan numaranın öneki ile ne yapılacağını açıklar:

• AsIs - öneki değiştirme: +,00 ⇒ +,00
• Off - öneki hariç tut: +,00 ⇒ X
• Plus - 'artı' işaretini kullanın: +,00 ⇒ +
• Zeros - sıfırları önek olarak kullanın: +,00 ⇒ 00

MaxLength (Number Expression) - Telefon numarasında tutulacak maksimum rakam sayısı.

Örneğin, MaxLength=6 ise, telefon numarası yalnızca son 6 hanesi alınarak dönüştürülecektir:
+123456789 ⇒ 456789.
İfade boşsa numara değiştirilmez.

Burada [MaxLength] değişkenini kullanarak 3CX Konsolu > Contacts > Options'da yapılandırılan değeri alabilirsiniz.

Bağlantı Elemanı

Bu öğe, CRM için bağlantıya özgü seçenekleri açıklar. Aşağıdaki özelliklere sahiptir:

MaxConcurrentRequests (integer) - CRM'e aynı anda kaç istek gönderilebileceğini belirtir. Bir istek, tek bir çağrı için bir numara araması olarak kabul edilir. Lütfen aynı çağrı için birçok sorgunun (örneğin kişiler, potansiyel müşteriler veya hesaplar için sorgulanacak farklı senaryolar) bir olarak sayıldığını unutmayın.

Parametreler Elemanı

Bu öğe, kullanıcı tarafından 3CX Admin Console'dan yapılandırılabilen değişkenler olan bir alt <Parameter> öğeleri koleksiyonu içerir. Her alt <Parameter> öğesinin aşağıdaki nitelikleri vardır:

• Name (string) - Parametrenin adı. Parametre değeri köşeli parantez içinde adı belirtilerek elde edilebilir. Örneğin: [BazıParametreler]
• Type (enum) - Parametrenin türü. Şu anda 7 tip mevcuttur:

• String - bir dizeyi temsil eder
• Password - kullanıcı arayüzünde gizli bir dizeyi temsil eder
• Boolean - bir onay kutusunu temsil eder
• Integer - bir tam sayıyı temsil eder
• Double - kayan nokta sayısını temsil eder
• DateTime - tarih ve saati temsil eder
• OAuth - OAuth yetkilendirme akışını tetiklemek için bir düğmeyi temsil eder

• Title (String) - Bu parametre için 3CX Admin Console'da gösterilecek başlık.
• Default (String Expression) - Parametrenin varsayılan değeri.
• Parent (string) - Bu, yapılandırma kullanıcı arayüzünde alt parametreleri bir kutuya gruplamak için bir üst parametrenin adıdır. Burada sağlanan metin bir parametre adı değilse, tüm alt parametreleri gruplayan kutunun etiketi bu öznitelik ten alınacaktır.
• Editor (enum) - Metin girmek için kullanılacak düzenleyici türü. Olası değerler, 100 karaktere kadar girmenize izin veren String ve 1000 karaktere kadar girmenize izin veren Sql'dir.
• RequestUrl (String Expression) - OAuth kimlik doğrulama akışını başlatmak için açılması gereken URL, yalnızca parametre türü OAuth olduğunda geçerlidir.
• RequestUrlParameters (String Expression) - Parametre türü OAuth olduğunda, RequestUrl ile birleştirilecek OAuth parametreleri.
• ResponseScenario (string) - OAuth sunucusu tarafından döndürülen yenileme belirtecini almak için yürütülmesi gereken senaryonun kimliği. Yalnızca parametre türü OAuth olduğunda geçerlidir.

Örnek (Zoho şablonundaki Parametreler düğümüne bakın):

Kimlik Doğrulama Elemanı

Bu öğe CRM tarafından kullanılan kimlik doğrulama yöntemini tanımlar. Şu anda üç seçenek var:

• No authentication: Type="No" Bu seçenek, kimlik doğrulama olmadığında veya CRM’in özel bir kimlik doğrulama mekanizması kullandığında, örneğin sorgu dizesindeki bazı parametrelerde kullanılır.
• Basic authentication: Type="Basic" Bu durumda, CRM'e gönderilen her HTTP isteği, <Value alt öğesinden alınan değeri kullanarak temel kimlik doğrulama protokolüne göre kodlanmış Yetkilendirme başlığını içerecektir.ğını içerecektir.
• Scenario authentication: Type="Scenario" Bu tür kimlik doğrulamasıyla, OAuth dahil olmak üzere karmaşık kimlik doğrulama senaryolarını tanımlamak mümkündür. Buradaki fikir, CRM'e belirli istekleri kullanarak, istekler için kullanmamız gereken başlığı ve/veya diğer parametreleri (örneğin, OAuth access token), belirteç son kullanma tarihi vb. almak için bir senaryoyu çağırmaktır.

Lütfen yalnızca Çıktıların değil, kimlik doğrulama senaryosunda yakalanan veya bildirilen tüm Değişkenlerin sonraki istekler için erişilebilir olduğunu unutmayın.

Senaryolar Elemanı

Bu öğe, CRM ile etkileşim kurarken kullanılacak farklı senaryoları açıklar. Örneğin, bir senaryo bir kimlik doğrulama akışını açıklayabilir, başka bir senaryo kişileri sorgulamanın nasıl yapılacağını, yeni bir kişinin nasıl oluşturulacağını, bir çağrının nasıl raporlanacağını vb. açıklayabilir. Bu öğe, <Scenario> alt öğelerinin bir koleksiyonunu içerir.

Senaryo, veri işlemenin ana birimidir ve şu şekilde çalışır:

1. CRM'e bir HTTP isteği veya veritabanı sorgusu gerçekleştirir.
2. Sonuçları kurallara ve yanıt verilerine (JSON veya XML) göre böler ve filtreler.
3. Her sonuç için yanıt verisinden alınan değişkenleri doldurur ve bir çıktı sağlar veya id’ye göre yinelemeli olarak bir iç senaryoyu çağırır.

Senaryo öğesi, her senaryo için benzersiz bir tanımlayıcı veya boş bir dize içeren Id (string) adlı bir öz niteliğe sahiptir. Bazı Kimliklerin özel bir anlamı vardır:

• Id alanı boş bırakıldığında senaryo telefon numarası kullanılarak kişi araması için kullanılır.
• Id "LookupByEmail" ile başladığında senaryo, e-posta adresi kullanılarak kişi araması için kullanılır.
• Id "SearchContacts" ile başladığında senaryo, CRM'de kişileri serbest metin kullanarak aramak için kullanılır; yani ad, soyad, şirket adı, telefon numaraları veya e-posta adreslerine göre arama yapılır.
• “ReportCall” kimliği çağrı günlüğü tutmak için kullanılır. Çağrı sona erdiğinde, bu senaryo yürütülecektir.
• “ReportChat” kimliği sohbet günlüğü tutmak için kullanılır. Sohbetle ilgilenildiğinde, bu senaryo yürütülecektir.
• "CreateContactRecordFromClient" kimliği, bir 3CX istemcisi tarafından talep edildiğinde CRM'de otomatik olarak yeni bir ilgili kişi kaydı oluşturmak için kullanılır.
• Aşağıdaki kimlikler, bir CFD uygulamasından kişi araması yapmak için kullanılır: "LookupFromCFD_Contacts_LookupNumber", "LookupFromCFD_Contacts_LookupID", "LookupFromCFD_Contacts_LookupFreeQuery", "LookupFromCFD_Leads_LookupNumber", "LookupFromCFD_Lead" s_LookupID”, “LookupFromCFD_Leads_LookupFreeQuery”, “LookupFromCFD_Accounts_LookupNumber”, “LookupFromCFD_Accounts_LookupID”, “LookupFromCFD_Accounts_LookupFreeQuery”.
• Herhangi bir diğer Id, standart senaryo türlerinden birinden alt senaryoları çağırarak belirli amaçlar için kullanılabilir. Örneğin, boş bir Kimlik içeren arama senaryosu yalnızca bir contact id döndürebilir ve ardından iletişim bilgilerini almak için başka bir senaryo gerekir.

Ayrıca Scenario elemanı, şu şekilde tanımlanabilen "Type" niteliğini kullanarak senaryo türünü tanımlar:

• “REST”: scenario, bir HTTP isteği kullanarak bir REST API'yi çalıştıracaktır.
• “SQLDatabase”: scenario bir SQL Veritabanı sorgusu yürütmektir. Desteklenen SQL veritabanları MySQL, PostgreSQL ve Microsoft SQL Server'dır.
• “NoSQLDatabase”: scenario bir No SQL Database  komutunu yürütmektir. Desteklenen tek NoSQL veritabanı MongoDB'dir.

Son olarak, Scenario elemanı, bir şablon birden fazla arama senaryosu içerdiğinde arama sırasını tanımlamak için "EntityId" ve "EntityOrder" öz niteliklerine sahiptir. "EntityId" özniteliği, örneğin Contacts, Leads veya Accounts gibi aranacak varlığı tanımlar. "EntityOrder" özniteliği genellikle değeri bir parametreden alır, böylece kullanıcı arama sırasını ayarlayabilir. Parametre, virgülle ayrılmış değerlerin yer aldığı bir liste olmalı ve her değer, varlıkların bir eğik çizgiyle ayrıldığı sırayı tanımlamalıdır. Bu parametre tanımı örneğini düşünün:

Senaryo düğümünün şu alt öğeleri vardır: Request, Query, Command, Rules, Variables ve Outputs.

İstek elemanı

Senaryo türü REST (varsayılan değer) olduğunda bu alt öğe zorunludur, çünkü senaryo bir HTTP isteği gerçekleştirmelidir. İstek öğesinin aşağıdaki özellikleri vardır:

• SkipIf (Boolean Expression) - İfade doğru olarak değerlendirilirse istek atlanır. Bu, bu senaryo için tüm değişkenlerin boş olarak ayarlanacağı ve çıktının yalnızca AllowEmpty özniteliği true olarak ayarlandığında sağlanacağı anlamına gelir.
• URL (String Expression) - Senaryo yürütüldüğünde çağrılacak URL.
• RequestType (enum) - HTTP istek yöntemi: Get - GET istekleri için. Post - POST istekleri için.
• RequestContentType (String) - HTTP isteği için kullanılacak Contact Type.
• RequestEncoding (enum) - POST isteği için kullanılan kodlama. Geçerli değerler şunlardır: Json, UrlEncoded. Json seçildiğinde, <PostValues> elemanının içinde <Object/>, <Array/> ve <Value/> alt elemanlarını kullanarak gelişmiş Json nesneleri oluşturabilirsiniz. Lütfen Zoho şablonunda bir örneğe bakın, CreateCall senaryosu.
• Message (String Expression) - POST isteği için HTTP Content olarak kullanılacak metin.
  Get istekleri için geçerli değildir. İsteğe bağlı olarak bu, RequestEncoding özniteliğinde açıklandığı gibi bir alt <PostValues> elemanı kullanılarak ayarlanabilir. Lütfen <PostValues> alt elemanı tanımlanmışsa bu özniteliğin ayarlanmaması gerektiğini unutmayın.
• ResponseType (enum) - Beklenen yanıt türü. Geçerli değerler şunlardır: Json ve Xml.

RequestType Post olduğunda, key-value pairs’ın bir koleksiyonu alt elemanlar olarak tanımlanabilir. Bu durumda, istek şu şekilde görünecektir:

Request elemanı ayrıca bir Headers alt elemanına da sahip olabilir. Burada belirtilen başlıklar HTTP isteğinde gönderilecektir. Bu elemanın aşağıdaki gibi bir dizi alt elemanı <Value> elemanına sahip olacaktır:

Sorgu elemanı

Senaryo türü SQLDatabase olduğunda bu alt eleman zorunludur, çünkü senaryo bir SQL sorgusu yürütmelidir. Sorgu öğesi aşağıdaki öznitelikleri vardır:

• SkipIf (Boolean Expression) - İfade doğru olarak değerlendirilirse, sorgu atlanır. Bu, bu senaryo için tüm değişkenlerin boş olarak ayarlanacağı ve çıktının yalnızca AllowEmpty özniteliği true olarak ayarlandığında sağlanacağı anlamına gelir.
• DatabaseType (enum) - sorgunun yürütüleceği veritabanı türü. Bu MySQL, MsSQL veya PostgreSQL olabilir.
• ConnectionString (String Expression) - veritabanına bağlanmak için kullanılacak bağlantı dizesi.
• StatementPasses (Integer) - Statement ifadesinin değerlendirilmesi gereken zaman sayısı. Varsayılan değer 1'dir, ancak iç içe ifadeler kullanılıyorsa daha yüksek bir değere ihtiyaç duyulabilir. Örneğin, Statement bir parametre kullanıyorsa ve parametre değeri başka bir parametre kullanıyorsa değer 2 olarak ayarlanmalıdır.
• Statement (String Expression) - veritabanında yürütülecek SQL ifadesi. Bu ifade, StatementPasses'te belirtilen sayıda yinelemeli olarak değerlendirilecektir.

Komut elemanı

Senaryo türü NoSQLDatabase olduğunda bu alt eleman zorunludur, çünkü senaryo bir No SQL komutu yürütmelidir. Command elemanı aşağıdaki özniteliklere sahiptir:

• SkipIf (Boolean Expression) - İfade doğru olarak değerlendirilirse, komut atlanır. Bu, bu senaryoya ilişkin tüm değişkenlerin boş olarak ayarlanacağı ve çıktının yalnızca AllowEmpty özniteliği true olarak ayarlandığında sağlanacağı anlamına gelir.
• DatabaseType (enum) - komutun yürütüleceği veritabanı türü. Bu MongoDB olmalıdır.
• ConnectionString (Dize Expression) - veritabanına bağlanmak için kullanılacak bağlantı dizesi.
• Database (String Expression) - kullanılacak veritabanının adı.
• Collection (String Expression) - kullanılacak koleksiyonun adı.
• CommandType (enum) - yürütülecek komut türü. Bu Filter veya Insert olabilir.
• CommandPasses (Integer) - Command ifadesinin değerlendirilmesi gereken sayı. Varsayılan değer 1'dir ancak iç içe geçmiş ifadeler kullanılırsa daha yüksek bir değere ihtiyaç duyulabilir. Örneğin, Command bir parametre kullanıyorsa ve parametre değeri başka bir parametre kullanıyorsa, değer 2 olarak ayarlanmalıdır.
• Command (String Expression) - veritabanında yürütülecek komut. Bu ifade, CommandPasses'te belirtilen sayıda yinelemeli olarak değerlendirilecektir.
• CommandData - komutu belirtmenin farklı bir yolu. Bazı durumlarda komutu iç içe XML elemanları kullanılarak belirtmek tercih edilir. Bu elemanlar komut yürütüldüğünde otomatik olarak JSON'a dönüştürülür. <CommandData> elemanı, <Command> elemanının bir alt elemanıdır ve içinde iç içe <Object/>, <Array/> veya <Value/> elemanları bulunabilir. Bu konuda daha fazla ayrıntı için MongoDB örneğine bakın.

Kurallar

Bu öğe, sunucu tarafından döndürülen yanıtı analiz etmek için kullanılır. Yanıt JSON, XML veya düz metin olabilir ve otomatik olarak ağaç görünümü yapısına dönüştürülür. Yapının her düğümü 3 türden biri olabilir:

1. Bir dizi eleman: benzer elemanların isimlendirilmemiş kümesi.
2. İsimlendirilmiş özelliklere sahip bir eleman.
3. Değerin kendisi: Düğüm ağacın bir leaves’ı olduğunda, temel bir türün değeridir.

Bu yanıt ağacını işlerken 2 görevi gerçekleştirmemiz gerekiyor:

1. Sunucu tarafından döndürülen her bir kişi için kök elemanı tanımlayın.
2. İhtiyacımız duyduğumuz kişileri isteğe olarak filtreleyin.

Bir senaryonun bir veya daha fazla alt elemanı <Rules> olabilir. Ayrıca, her <Rules> elemanının bir veya daha fazla alt elemanı <Rule> olabilir. Döndürülen veriler (JSON, XML veya Düz Metin) bu kurallara göre işlenir ve her kayıt aşağıdaki durumlarda filtreden geçer:

• <Rules> elemanından en az bir <Rule> elemanı filtreyi geçer (<Rule> elemanları bir OR koşuluyla değerlendirilir).
• AND her <Rules> elemanı, önceki maddeye göre filtreden geçer (<Rules> elemanları AND koşuluyla değerlendirilir).

<Rule> elemanının içindeki değer, yanıt veri ağacındaki eşleşen elemanın yoludur ve bu elemanın özellikleri şunlardır:

• Type (enum) - Eşleştirme kuralı türü; aşağıdakilerden biri olabilir:

• Any - kural, filtreleme olmaksızın yanıt veri ağacında kişinin kökünü belirlemek kullanılırsa.
• Number - kuralın veri elemanını (yol tarafından sağlanan) telefon numarasıyla eşleşmesi gerekip gerekmediği.
• Equals - kuralın veri elemanını (yol tarafından sağlanan) Ethalon özelliğinde belirtilen değerle eşleştirmesi gerekip gerekmediği.

• Ethalon (String Expression) - Type=Equals olduğunda kullanılacak ifade. Ethalon'un dize gösterimi veri eleman içeriğiyle eşleşirse kural geçerli olur.

Bu, bir CRM tarafından döndürülen JSON yanıtının bir örneğidir:

Yol, yanıt ağacındaki belirli bir düğümü işaret eden bir ifadedir. Bu ifade, noktalarla ayrılmış düğüm adlarını birleştiren bir dizedir. Yol ifadesi, seçilen elemanın değerine işaret eder, dolayısıyla, yol bir leaves’a işaret ediyorsa, temel değer döndürülür ve bir diziye işaret ediyorsa elemanların dizisi döndürülür.

Yukarıdaki JSON örneğinde şunu görebiliriz:

• "result" yolu, kişiler dizisine işaret eder.
• “result.lastName” yolu “Bravo” ve “Lecter” değerlerine sahip 2 leaves’a işaret eder.
• "result.communicationItems.type.name" yolu, "Direct", "Email", "Cell" ve "Direct" değerlerine sahip 4 leaves’ı işaret eder.

Farklı <Rule> elemanlarının nasıl çalıştığını görelim. Aşağıdaki kuralı ele alalım:

Bu kural, sonuç düğümünde firstName özelliği olan her kaydı döndürür. Bu kuralı geçen 2 kayıt vardır ve bu nedenle kişilere dönüştürülecektir: biri "Johnny Bravo" ve diğeri "Hannibal Lecter" için.

Kuralı şu şekilde değiştirirsek:

..bunun sonucunda “Hannibal Lecter” için tek bir kayıt ortaya çıkacak.

Karşılaştırma yapmak gerekirse, aşağıdaki kuralı kullanarak:

..4 kayıtla eşleşecek, 3'ü “Johnny Bravo” için ve 1 tanesi “Hannibal Lecter” için.

Kuralları şu şekilde değiştirirsek:

..ilk kural 3 “Phone” kaydını filtreleyecektir (Johnny Bravo için doğrudan telefon ve cep telefonu, Hannibal Lecter için doğrudan telefon). İkinci filtre sonucu arayan numarayla eşleşen numaralarla sınırlayacaktır. Yani örneğin, “987654” numarasını arıyorsak, filtrelerden yalnızca “Johnny Bravo” için bir kayıt geçecektir. Ve MaxLength=6 ile "123456" numarasını arıyorsak, filtrelerden iki kayıt geçecektir, biri "Johnny Bravo" için "123456" numarası, diğeri "Hannibal Lecter" için "+1123456" numarası.

Değişkenler

Kuralları sunucu tarafından döndürülen verilere uyguladıktan sonra, değişkenleri ihtiyacımız olan veri parçalarıyla doldurmamız gerekir. İhtiyacımız olduğu kadar değişken tanımlayabiliriz.

Bir senaryonun yalnızca bir alt elemanı <Variables> olabilir. Ve bu elemanın ihtiyacımız olan sayıda alt elemanı <Variable> olabilir. Alt eleman <Variable> elemanının içindeki değer, yanıt veri ağacındaki eşleşen elemanın yoludur ve bu elemanın nitelikleri şunlardır:

• Name (string) - Değişkenin adı.
• Path (string) - Yanıt veri ağacındaki eşleşen öğenin yolu. Bu aynı zamanda eleman değeri olarak da belirtilebilir.
• LookupValue (string) - bu öznitelik ayarlandığında, arama tersine çevrilir ve değişkene belirtilen değeri içeren yolun anahtarı atanır. Örneğin, yanıt ağacı "result.phones.1234567890=work" ise yol "result.phones" ve LookupValue="work" olarak ayarlanırsa, değişkene "1234567890" değeri atanır.

Ağacın kökünden kişinin köküne kadar olan yolda diziler varsa, bu özel kişiye ait örnek seçilecektir. Ancak temasın kökünden son leaves’a giden yolda diziler varsa ve hiçbir değişken filtrelemesi uygulanmazsa, bir istisna atılacaktır.

Yukarıdaki örnekteki JSON yanıtına devam ederek, iletişim kökünü filtrelemek için aşağıdaki kuralımız olduğunu varsayalım:

Bu durumda adı, soyadı ve şirket adını almak için kolayca değişkenler oluşturabiliriz:

Ancak bu, telefon numaraları ve e-posta için işe yaramaz çünkü bu bilgiler dizilerde depolanır ve e-posta ve her telefon numarası türü için "result.communicationItems.value" yolunun hangi leaves’ın alınması gerektiğini tanımlamak mümkün değildir. Bu durumda belirsizliği gidermek için değişken filtrelemesi kullanmamız gerekir.

Değişken

Her değişken, bir diziden birden fazla leaves’ın belirsizliğini ortadan kaldırmak için filtre sağlayabilir ve her durum için yalnızca ihtiyacımız olanı seçebilir. Değişken filtresi, genel Kurallar ile aynı prensibe dayanır ancak yalnızca bir kural kümesi içerir ve kayıt dizisini temasın kökünden son leaves’a kadar filtreler.

Örneğimizden, “Johnny Bravo” kişisinin üç iletişim Elemanına sahip olduğunu görebiliriz: 2 telefon ve 1 e-posta. Bu bilgiyi değişkenlere almak için aşağıdaki filtreleri uygulayabiliriz:

Her değişken yolu ancak filtreleri farklı olduğundan motor her değişken için doğru değeri okur.

Çıktılar

Değişkenleri sunucunun döndürdüğü verilerden alınan değerlerle doldurduktan sonra, senaryonun çıktısını, yani tüm bu işlemlerin sonucunu tamamlamamız gerekir. Bunu yapmak için <Outputs> elemanını kullanırız. 2 farklı çıktı türü vardır:

• Çıkış değerlerini sağlamak için: Bu senaryo zinciri işlenmeyi durdurur. Bu durumda <Outputs> elemanının ihtiyacımız olan kadar <Output> alt elemanı vardır, her çıktı değeri için bir tane.
• Başka bir (chained) senaryo çalıştırmak için: bu durumda Next niteliği, takip eden senaryonun Id'sine ayarlanır ve çıktı, bunun yerine bir sonraki senaryo tarafından sağlanır.

Çıktı değerleri sağlayan senaryo bunu 2 durumda yapabilir:

1. Senaryo kurallarına uyan en az bir kayıt olduğunda.
2. AllowEmpty özelliği true olarak ayarlandığında.

<Outputs> öğesinin özellikleri şunlardır:

• Next (string) - Varsa, yürütülecek aşağıdaki senaryonun Id’si.
• AllowEmpty (bool) - Doğru olduğunda senaryo, senaryo kurallarına uyan bir kayıt olmasa veya tüm istek atlanmış olsa bile bir çıktı sağlar. Bu durumda çıktı, tüm değerler için boş bir değere sahip olacaktır.
  Bu, bir zincirdeki bazı ara senaryoları, bir nedenden dolayı atlamak istediğinizde yararlıdır. Örneğin, ana iletişim verilerini (ad, soyad, şirket kimliği vb.) almak için bir isteğe ve şirket adını kimliğine göre almak için ikinci bir zincirleme isteğe ihtiyacınız vardır. İletişim bir şirketle ilişkilendirilmemiş ise, ikinci istek hiçbir kayıt döndürmez. Bu durumda, AllowEmpty belirtilmemişse, bu iletişimden herhangi bir bilgi döndürmez ve bu yanlıştır çünkü iletişim hala geçerlidir.
  

<Outputs> elemanı çıktı değerleri sağladığında, alt <Output> elemanlarını içerir. Her alt <Output> elemanı aşağıdaki özelliklere sahiptir:

• Type (string) - Çıktı değerinin türü. Daha fazla ayrıntı için her senaryo türü için Çıktı bölümüne bakın.
• Passes (integer) - Değer ifadesinin değerlendirilmesi gereken sayı. Bazı durumlarda, Değer, aynı zamanda bir ifade olan bir parametreye ayarlanır ve Değeri yalnızca bir kez değerlendirmek yeterli olmaz. Bu durumlarda burada daha büyük bir değere ihtiyaç duyulur, genellikle 2. Varsayılan değer 1'dir.
• Value (string Expression) - Çıktıya verilecek değeri oluşturacak ifade.
  

Örneğin, aşağıdaki çıktı, değişkenleri eklemek için ifadeleri kullanarak bir kişi araması için sonucu ayarlar:

Her senaryo türü için çıktılar

4 tür senaryo vardır:

İletişim bilgilerini döndüren senaryolar

Aşağıdaki senaryolar iletişim bilgilerini döndürecektir:

• Kimliği olmayan telefon numarasına göre kişi arama.
• "LookupByEmail" ön ekiyle başlayan e-posta senaryolarına göre kişi arama.
• "SearchContacts" ön ekiyle başlayan kişi arama senaryoları.
• “CreateContactRecordFromClient” kimliğine sahip kişi oluşturma senaryosu.

Tek bir şablon için bu türden birçok senaryoya sahip olmak mümkündür. Birden fazla senaryo olması durumunda, bunlar şablonda yer aldıkları sırayla birbiri ardına yürütülür ve sonuç birleştirilir. Sıra, yukarıda açıklanan arama sıralama tekniği kullanılarak çalışma zamanında ayarlanabilir.

Bu senaryo için çıktı türleri şunlardır: (All are string Expression)

• FirstName - Kişinin adı
• LastName - Kişinin soyadı
• Email - Kişinin e-postası
• CompanyName - İlgili kişinin şirket adı
• ContactUrl - CRM'deki kişinin URL'si - bu zorunludur, çünkü bu, 3CX'teki kişinin tanımlayıcısıdır.
• PhoneMobile - Kişinin cep telefonu
• PhoneMobile2 - Kişinin ek cep telefonu
• PhoneHome - Kişinin ev telefonu
• PhoneHome2 - Kişinin ek ev telefonu
• PhoneBusiness - Kişinin iş telefonu
• PhoneBusiness2 - Kişinin ek iş telefonu
• PhoneOther - Kişinin diğer telefonu
• FaxBusiness - Kişinin iş faksı
• FaxHome - Kişinin ev faksı
• Pager - Kişinin çağrı cihazı
• PhotoUrl - Kişinin fotoğrafının URL'si
• EntityId - Arama ve sohbet günlüğü tutma sırasında erişilebilecek eşleşen varlığın (iletişim, potansiyel müşteri veya hesap) kimliği
• EntityType - Arama ve sohbet günlüğü tutma sırasında erişilebilecek eşleşen varlığın (iletişim, potansiyel müşteri veya hesap) türü

ÖNEMLİ: Bir kaydın geçerli bir eşleşme olarak kabul edilebilmesi için şablonun aşağıdaki çıktıları döndürmesi gerekir:

• ContactUrl: Yukarıda belirtildiği gibi bu zorunludur ve her kişi için benzersiz olmalıdır.
• FirstName, LastName veya CompanyName: Bu çıktılardan birinin bir değeri olmalıdır.
• PhoneMobile, PhoneMobile2, PhoneHome, PhoneHome2, PhoneBusiness, PhoneBusiness2, PhoneOther, FaxBusiness, FaxHome, veya Pager: Telefon numarasına göre arama çalıştırıldığında, bu çıktılardan birinin değeri aranan telefon numarasına ayarlanmalıdır.
• Email: E-postayla arama yapıldığında bu değerin aranan e-postaya ayarlanması gerekir.

Kimlik Doğrulama Senaryosu

Şablon başına yalnızca bir kimlik doğrulama senaryosuna izin verilir. Bu senaryo Kimlik Doğrulama bölümünden tetiklenir ve Kimlik, orada belirtilen Değerle eşleştirilir.

Kimlik Doğrulama Senaryosu aşağıdaki durumlarda çağrılır:

1. CRM'e yapılan ilk sorguda.
2. Token süresi dolduğunda veya token süresi belirtilmediğinde ve kimlik doğrulama senaryosuna son çağrı 1 saatten daha önce yapılmışsa.

Bu senaryoya ilişkin çıktı türleri şunlardır:

• Bearer (string Expression) - Sağlanırsa, gönderilen her istek için Kimlik Doğrulama başlığında kullanılacak Taşıyıcı değeri.
• BearerExpiration (integer Expression) - Taşıyıcının sona ermesi için saniye cinsinden zaman aşımı. Kimlik Doğrulama Senaryosu bu zaman aşımı süresi dolana kadar tekrar çağırılmayacaktır. Sona erme hatalarından kaçınmak için bu parametreyi gerçek sona erme zaman aşımından bir dakika daha az ayarlamanızı öneririz.
• HeaderName (string Expression) - Sağlanırsa, CRM'e yapılan her istekte kullanılacak özel istek başlığının adı.
• HeaderValue (string Expression) - Sağlanırsa, CRM'e yapılan her istekte kullanılacak özel istek başlığının değeri.

Not: En az bir başlık sağlanmalıdır: Bearer veya HeaderName/HeaderValue.

OAuth Yanıt Senaryosu

Şablon OAuth2 kimlik doğrulaması kullanıldığında, OAuth türünde bir parametre olmalıdır. Bu durumda, 3CX Yönetici Konsolu bir Yetkilendir düğmesi gösterecektir. Kullanıcı bu düğmeye bastığında, CRM'in Yetkilendirme sayfasını gösteren yeni bir sekme açılacaktır. Kullanıcı CRM verileri için, 3CX’e erişim izni verdiğinde, CRM tarayıcı sekmesini bir yetkilendirme kodu sağlayarak bir 3CX sayfasına yönlendirir. Bu kod daha sonra yönetici konsolu tarafından Refresh Token oluşturmak için kullanılır. Bu son işlem, OAuth Yanıt Senaryosu yürütülerek yapılır. Bu konuda daha fazla ayrıntı için lütfen Zoho şablonunu kontrol edin.

Bu senaryoya ilişkin çıktı türleri şunlardır:

• Result (string Expression) - bu senaryo ile elde edilen refresh token’idir.

Zincirleme senaryo

Önceki senaryo türlerinden herhangi biri görevi tamamlamak için zincirleme bir senaryoyu çağırabilir. Bu durumda, zincirleme bir senaryo çıktı olarak yapılandırılır ve bu senaryo gerçek çıktıyı sağlar. Zincirleme senaryo, Rules filtreleri tarafından döndürülen her sonuç için yürütülür. Örneğin, bu çıktı "GetContactId" kimliğine sahip zincirleme bir senaryoyu çağırır:

<Outputs Next="GetContactId"/>

Zincirleme senaryo, ana senaryoda ayarlanan her değişkene erişebilir.

Senaryo yürütme zinciri iki durumda sonlanır:

1. Son senaryoya ulaşılır ve çıktılar ayarlanır.
2. Senaryonun isteği boş bir yanıt üretir (veya filtreyi geçen kayıt yoktur) ve çıktı için AllowEmpty niteliği false olarak ayarlanır.

OAuth2 kimlik doğrulama akışı oluşturma

Tam bir örnek için Zoho şablonuna bakın.

1. CRM sağlayıcınızdan ClientId ve ClientSecret'ı alın.
2. CRM sağlayıcınızda 3CX Telefon Sistemi OAuth2 URL'sine izin verin. (Örneğin) “https://my-pbx.example.com:5001/api/oauth2crm” olarak ayarlanmalıdır
3. Parametreler bölümünde OAuth türünde bir Parametre oluşturun. Bu, yetkilendirme kodunu almak için kullanılacaktır. RequestUrl ve RequestUrlParameters niteliklerinde diğer Parametre değerlerini kullanabilirsiniz. RequestUrlParameters otomatik olarak urlencode edilirken RequestUrl bozulmadan kalacaktır. Yetkilendirme kodunu almak için parametrelerin nasıl oluşturulacağı konusunda lütfen CRM sağlayıcınıza danışın. [State] ve [RedirectUri] özel parametrelerini iletilmesi zorunludur. [State]'i ayrı olarak iletebilir (Zoho’ya bakın) veya [RedirectUri] ile birleştirebilirsiniz. Genellikle en azından client_id ve redirect_url parametreleri zorunludur.
4. Refresh token almak için kullanılacak bir yanıt senaryosu oluşturun ve adını ResponseScenario özniteliğine ayarlayın. Lütfen refresh token’ını nasıl alacağınız konusunda CRM sağlayıcınıza danışın. Genellikle bu bir POST Json isteğidir ve en azından client_id ve client_secret parametreleri zorunludur.
5. Type=”Scenario” ile Kimlik Doğrulama düğümünü oluşturun ve access token almak için bir senaryo oluşturun. Access token nasıl alınacağınız konusunda lütfen CRM sağlayıcınıza danışın. Genellikle bu bir POST Json isteğidir ve en azından refresh_token, client_id ve client_secret parametreleri zorunludur.

Expressions

expressions motoru aşağıdakileri kullanarak değerler oluşturmamıza olanak tanır:

• Variables

• String concatenation

• Method invocation

• Condition evaluation

Dize değişmezleri ve değişkenler içeren bir ifade oluştururken, dize değişmezinizde bazı belirli karakterleri kullanmanız gerekirse, ifade için özel anlam taşıdıkları için bunlardan kaçmanız gerekecektir. Bu karakterler şunlardır:

• Açılan köşeli parantez [ yerine {{ kullanılması gerekiyor.
• Kapanan köşeli parantez ] yerine }} kullanılması gerekiyor.
• Tırnak işareti " yerine ^^ kullanılması gerekiyor.

Değişkenler

Bir değişken değeri elde etmek için, SQL sorgusu çağırırken hariç her yerde, köşeli parantezler içinde değişken adını kullanın: [SomeVariable]

SQL sorguları için değişken değerleri, @ karakter öneki kullanılarak adlandırılmış parametreler kullanılarak elde edilir, örneğin: @SomeVariable.

Değişkenler şu şekilde elde edilir:

• Predefined variables

• Input parameters

• Scenario variables

Önceden Tanımlanmış Değişkenler

Her senaryo türünde kullanabileceğiniz önceden tanımlanmış bazı değişkenler bulunur.

Aşağıdaki değişkenler numara ile kişi arama senaryoları için önceden tanımlanmıştır ve her zaman kullanılabilir:

• Number (string) - Numara Elemanına göre aranacak telefon numarası değiştirildi.
• CallDirection (string) - Kişi araması sırasında çağrı yönü "Inbound" veya "Outbound" olabilir.
• MaxLength (integer) - Eşleşecek basamak sayısı (sağdan sola doğru sayılır).
• FoundRecordCount (integer) - Döndürülen toplam kişi sayısı. Eşleşen senaryo zincirinin ne zaman bittiği belirlenir.

Aşağıdaki değişkenler e-posta ile kişi arama senaryoları için önceden tanımlanmıştır ve istenildiği zaman kullanılabilir:

• Email (string) - Aranacak e-posta.
• FoundRecordCount (integer) - Döndürülen toplam kişi sayısı. Eşleşen senaryo zincirinin ne zaman bittiği belirlenir.

Aşağıdaki değişkenler ilgili kişi arama senaryoları için önceden tanımlanmıştır ve istenildiği zaman kullanılabilir:

• SearchText (string) - Aranacak metin.
• FoundRecordCount (integer) - Döndürülen toplam kişi sayısı. Eşleşen senaryo zincirinin ne zaman bittiği belirlenir.

Aşağıdaki değişkenler kişi oluşturma senaryosu için önceden tanımlanmıştır ve istenildiği zaman kullanılabilir:

• FirstName (string) - Oluşturulacak kişinin ilk adı.
• LastName (string) - Oluşturulacak kişinin soyadı.
• Number (string) - Oluşturulacak kişinin numarası (sadece e-posta adresi girildiğinde boş olabilir).
• Email (string) - Oluşturulacak kişinin e-posta adresi (yalnızca telefon numarası girildiğinde boş olabilir).
• Company (string) - Oluşturulacak ilgili kişinin şirketin adı.

Aşağıdaki değişkenler rapor çağrı senaryosu için önceden tanımlanmıştır ve istenildiği zaman kullanılabilir:

• CallType (string) - Çağrının türü; “Inbound”, “Outbound”, “Missed” veya “Notanswered” olabilir.
• Number (string) - Harici iletişim numarası (giden aramalar için aranan numara veya gelen aramalar için arayanın numarası).
• CallDirection (string) - Çağrı yönü, “Inbound” veya “Outbound” olabilir.
• Name (string) - Eşleşen kişinin adı.
• EntityId (string) - Eşleşen varlığın kimliği (ilgili kişi, potansiyel müşteri veya firma).
• EntityType (string) - Eşleşen varlığın türü (ilgili kişi, potansiyel müşteri veya firma).
• QueueExtension (string) - Çağrı, yalnızca bir kuyruk veya zil grubu aracılığıyla temsilciye ulaştığında, kuyruk veya zil grubunun dahili numarası.
• Agent (string) - Aramayı gerçekleştiren temsilcinin dahili numarası.
• AgentFirstName (string) - Aramayı gerçekleştiren temsilcinin adı.
• AgentLastName (string) - Aramayı gerçekleştiren temsilcinin soyadı.
• AgentEmail (string) - Aramayı gerçekleştiren temsilcinin e-posta adresi.
• Duration (string) - Aramanın “hh:mm:ss” biçimindeki süresi.
• DurationTimespan (TimeSpan) - Kullanıcının istediği gibi biçimlendirilebilen bir TimeSpan nesnesi olarak çağrının süresi. Örneğin, [[[DurationTimespan].get_TotalMinutes()].ToString("F0")] ifadesi kullanılarak toplam dakika sayısını temsil eden bir dizeye dönüştürülebilir.
• DateTime (string) - 3CX sunucusundaki yerel kültür kullanılarak biçimlendirilen yerel saat diliminde çağrının başlangıç ​​tarihi ve saati.
• CallStartTimeLocal (DateTime) - Yerel saat diliminde, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak çağrının başlangıç ​​tarihi ve saati. Örneğin, [[CallStartTimeLocal].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• CallStartTimeUTC (DateTime) - UTC saat diliminde, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak çağrının başlangıç ​​tarihi ve saati. Örneğin, [[CallStartTimeUTC].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• CallEstablishedTimeLocal (DateTime) - Çağrının yerel saat diliminde kurulduğu tarih ve saat, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak. Örneğin, [[CallEstablishedTimeLocal].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• CallEstablishedTimeUTC (DateTime) - Çağrının UTC saat diliminde kurulduğu tarih ve saat, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak Örneğin, [[CallEstablishedTimeUTC].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• CallEndTimeLocal (DateTime) - Yerel saat diliminde, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak çağrının bitiş tarihi ve saati. Örneğin, [[CallEndTimeLocal].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• CallEndTimeUTC (DateTime) - UTC saat diliminde, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak çağrının bitiş tarihi ve saati. Örneğin, [[CallEndTimeUTC].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• CallStartTimeLocalMillis (integer) - Çağrının yerel saat dilimindeki başlangıç ​​tarihi ve saati, epoch’dan bu yana geçen milisaniye cinsinden ifade edilir (unix saati olarak da bilinir).
• CallStartTimeUTCMillis (integer) - Çağrının başlangıç ​​tarihi ve saati, UTC zaman diliminde, epoch’dan bu yana geçen milisaniye cinsinden ifade edilir (unix saati olarak da bilinir).
• CallEstablishedTimeLocalMillis (integer) - Çağrının yerel saat diliminde kurulduğu tarih ve saat, epoch’dan bu yana geçen milisaniye cinsinden ifade edilir (unix saati olarak da bilinir).
• CallEstablishedTimeUTCMillis (integer) - Çağrının kurulduğu tarih ve saat, UTC zaman diliminde, epoch’dan bu yana geçen milisaniye cinsinden ifade edilir (unix saati olarak da bilinir).
• CallEndTimeLocalMillis (integer) - Çağrının yerel saat dilimindeki bitiş tarihi ve saati, epoch’dan bu yana geçen milisaniye cinsinden ifade edilir (unix saati olarak da bilinir).
• CallEndTimeUTCMillis (integer) - Çağrının bitiş tarihi ve saati, UTC zaman diliminde, epoch’dan itibaren geçen milisaniye olarak ifade edilir (unix saati olarak da bilinir).
• Transcription (String) - Aramanın transkripsiyonlu metni.
• Summary (String) - Aramanın transkripsiyonunun özeti.
• RecordingUrl (String) - Gerçek çağrı kaydının indirilebileceği URL.

Aşağıdaki değişkenler rapor sohbet senaryosu için önceden tanımlanmıştır ve istenildiği zaman kullanılabilir:

• Number (string) - Harici iletişim numarası (yalnızca SMS aracılığıyla yapılan bir sohbet olduğunda kullanılabilir).
• Email (string) - Harici iletişim e-posta adresi (yalnızca Canlı Sohbet aracılığıyla yapılan bir sohbet olduğunda kullanılabilir).
• Name (string) - Eşleşen kişinin adı.
• EntityId (string) - Eşleşen varlığın kimliği (ilgili kişi, potansiyel müşteri veya firma).
• EntityType (string) - Eşleşen varlığın türü (ilgili kişi, potansiyel müşteri veya firma).
• QueueExtension (string) - Sohbet bir kuyruk aracılığıyla temsilciye ulaştığında, kuyruğun dahili numarası.
• ChatMessages (string) - Sohbet oturumu sırasında gönderilen ve alınan mesajlar.
• Agent (string) - Sohbeti yöneten temsilcinin dahili numarası.
• AgentFirstName (string) - Sohbeti yöneten temsilcinin adı.
• AgentLastName (string) - Sohbeti yöneten temsilcinin soyadı.
• AgentEmail (string) - Sohbeti yöneten temsilcinin e-posta adresi.
• Duration (string) - Sohbet oturumunun “hh:mm:ss” biçimindeki süresi.
• DurationTimespan (TimeSpan) - Sohbet oturumunun süresi, kullanıcının istediği gibi biçimlendirilebilen bir TimeSpan nesnesi olarak. Örneğin, [[[DurationTimespan].get_TotalMinutes()].ToString("F0")] ifadesi kullanılarak toplam dakika sayısını temsil eden bir dizeye dönüştürülebilir.
• DateTime (string) - 3CX sunucusundaki yerel kültüre göre biçimlendirilmiş, yerel saat diliminde sohbet oturumunun başlangıç ​​tarihi ve saati.
• ChatStartTimeLocal (DateTime) - Sohbet oturumunun yerel saat dilimindeki başlangıç tarihi ve saati, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak. Örneğin, [[ChatStartTimeLocal].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• ChatStartTimeUTC (DateTime) - Sohbet oturumunun başlangıç tarihi ve saati, UTC saat diliminde, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak. Örneğin, [[ChatStartTimeUTC].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• ChatEndTimeLocal (DateTime) - Sohbet oturumunun başlangıç tarihi ve saati, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak. Örneğin, [[ChatEndTimeLocal].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• ChatEndTimeUTC (DateTime) - Sohbet oturumunun UTC saat dilimindeki bitiş tarihi ve saati, kullanıcının istediği gibi biçimlendirilebilen bir DateTime nesnesi olarak. Örneğin, [[ChatEndTimeUTC].ToString("yyyy-MM-ddTHH:mm:ssZ")] ifadesi kullanılarak dizeye dönüştürülebilir.
• ChatStartTimeLocalMillis (integer) - Sohbet oturumunun yerel saat diliminde başlangıç ​​tarihi ve saati, epoch’dan bu yana geçen milisaniye olarak ifade edilir (unix saati olarak da bilinir).
• ChatStartTimeUTCMillis (integer) - Sohbet oturumunun başlangıç tarihi ve saati, UTC saat diliminde, Epoch’dan bu yana geçen milisaniye olarak ifade edilir (unix saati olarak da bilinir).
• ChatEndTimeLocalMillis (integer) - Sohbet oturumunun yerel saat diliminde bitiş tarihi ve saati, epoch’dan bu yana geçen milisaniye olarak ifade edilir (unix saati olarak da bilinir).
• ChatEndTimeUTCMillis (integer) - Sohbet oturumunun bitiş tarihi ve saati, UTC saat diliminde, epoch’dan bu yana geçen milisaniye olarak ifade edilir (unix saati olarak da bilinir).

Aşağıdaki değişkenler CFD'den Arama senaryoları için önceden tanımlanmıştır ve herhangi bir zamanda kullanılabilir:

• Number (string) - Arama Türü "Entity Number" olduğunda CFD uygulamasından alınan aranacak telefon numarası.
• EntityID (string) - Arama Türü "Entity ID" olduğunda CFD uygulamasından alınan, aranacak varlığın (iletişim, potansiyel müşteri veya hesap) kimliği.
• Query (string) - Arama Türü "Custom Query" olduğunda CFD uygulamasından alınan CRM'de arama yaparken kullanılacak sorgu.

Dize Birleştirme

Varsayılan olarak, ifade motoru bir ifadede bulunan dizeleri birleştirir. Örneğin, bir ifade değişkenler ve dize sabitleri içeriyorsa:

<Authentication Type="Basic">

        <Value>[CompanyName]+[PublicKey]:[PrivateKey]</Value>

</Authentication>

Değer, [CompanyName] değişkeninin değerinin, ardından "+" dize sabitinin, ardından [PublicKey] değişkeninin değerinin, ardından ":" dize sabitinin ve son olarak [PrivateKey] değişkeninin değerinin birleştirilmesinin sonu olacaktır.

Bir istek için URL oluşturmaya yönelik başka bir örnek:

<RequestUrl="[Domain]/rest/v10/Contacts?filter{{0}}{{phone_mobile}}{{$ends}}=[Number]&amp;fields=id,first_name,last_name,phone_mobile,email,accounts " ResponseType="Json"/>

...burada, [Domain] bir giriş parametresidir ve [Number] aranacak telefon numarasını içeren önceden tanımlanmış değişkendir. Kalan metin, dize sabiti olarak kabul edilir ve bu değişkenlerin değerleri ile birleştirilir.

Dize birleştirme modundan çıkıp yöntem çağırma ve koşul değerlendirme moduna girmek için, aşağıdaki bölümlerde gösterildiği gibi ifade içeriğini köşeli parantez içine almanız gerekir.

Yöntem Çağırma

Bu sözdizimini kullanarak bir değişkenin değeri üzerinde desteklenen herhangi bir yöntemi çağırabilirsiniz:

[[Variable].MethodName(param1;param2;...paramN)]

Örneğin, aranacak numara üzerinde URL kodlaması yapmak için "+" ifadesini "%2B" dizesiyle değiştirmek amacıyla aşağıdaki ifadeyi kullanabiliriz:

[[Number].Replace(&quot;+&quot;,&quot;%2B&quot;)]

Başka bir örnek olarak, Rapor Çağrısı senaryosu sırasında çağrının başlangıç ​​tarihini ve saatini biçimlendirmek istiyorsak şunu kullanabiliriz:

[[CallStartTimeUTC].ToString("yyyy-MM-dd")]

İlk örnekte, [Number] bir C# dizesidir, bu nedenle System.String sınıfından herhangi bir yöntem kullanılabilir. İkinci örnekte, [CallStartTimeUTC] bir C# DateTime nesnesidir, bu nedenle System.DateTime sınıfından herhangi bir yöntem kullanılabilir.

Durum Değerlendirmesi

Motor aşağıdaki operatörleri destekler:

• == (bool) - İki dizeyi karşılaştırır ve eşit olmaları durumunda true değerini döndürür
• != (bool) - İki dizeyi karşılaştırır ve eşit değillerse true değerini döndürür.
• > (bool) - İki IComparable nesnesini karşılaştırır ve birincisi ikinciden büyükse true değerini döndürür.
• || (bool) - Koşullu OR.
• && (bool) - Koşullu AND.
• + (integer float string) - Türlerine göre iki nesnenin toplamını döndürür.
• - (integer float) - Türlerine göre iki nesnenin çıkarımını döndürür.
• IIf(cond,res1,res2) - cond true olduğunda res1 değerini, aksi takdirde res2 değerini döndürür.

Örnek: https://[IIf([IsCloud]==true,"api-","")][Domain]...

Bu durumda, [IsCloud] değişkeni doğru olduğunda, uygun URL'yi oluşturmak için [Domain] değişkeninin değerine "api-" dize değeri eklenecektir. Lütfen “IIf” operatörünün etrafındaki köşeli parantezlere dikkat edin.

Çağrı Günlüğü

3CX Telefon Sistemi, harici aramaların CRM'de raporlanmasını destekler. Arama günlüğü tutmayı desteklemek için, yalnızca "ReportCall" ayrılmış adıyla bir senaryo oluşturmanız gerekir. Bu senaryo herhangi bir veri döndürmez, bu nedenle <Rules/>, <Variables/> ve <Outputs/> düğümleri sağlamamalısınız. Senaryo türüne göre yalnızca bir <Request>, <Query> veya <Command> elemanı gereklidir.

Çağrı Günlüğü örneklerini görmek için 3CX tarafından sağlanan CRM şablonlarını inceleyin.

Sohbet Günlüğü

3CX Telefon Sistemi, sohbetleri CRM'de raporlanmasını destekler. Sohbet günlüklerini desteklemek için, yalnızca "ReportChat" ayrılmış adıyla bir senaryo oluşturmanız gerekir. Bu senaryo herhangi bir veri döndürmez, bu nedenle <Rules/>, <Variables/> ve <Outputs/> düğümleri sağlamamalısınız. Senaryo türüne göre yalnızca bir <Request>, <Query> veya <Command> elemanı gereklidir.

Sohbet Günlüğü örneklerini görmek için 3CX tarafından sağlanan CRM şablonlarını inceleyin.

CFD uygulamasından arama

3CX Telefon Sistemi, bir CFD uygulamasından CRM'de kişileri aramayı destekler. Bunu desteklemek için, aşağıdaki ayrılmış adlardan bir veya daha fazlasıyla bir senaryo oluşturmanız yeterlidir:

• “LookupFromCFD_Contacts_LookupNumber”
• "LookupFromCFD_Contacts_LookupID"
• "LookupFromCFD_Contacts_LookupFreeQuery"
• "LookupFromCFD_Leads_LookupNumber"
• "LookupFromCFD_Leads_LookupID"
• "LookupFromCFD_Leads_LookupFreeQuery"
• “LookupFromCFD_Accounts_LookupNumber”
• “LookupFromCFD_Accounts_LookupID”
• “LookupFromCFD_Accounts_LookupFreeQuery”

Bu senaryolar, CRM'den alınan JSON veya XML'i CFD uygulamasına döndürecektir. Bu senaryoya hiçbir çıktı dahil edilmemelidir.

CFD senaryolarından arama örneklerini görmek için 3CX tarafından sağlanan CRM şablonlarını kontrol edin.

Hata ayıklama

3CX Sistem Hizmeti, sistemdeki her gelen ve giden çağrı için sunucu tarafı CRM motorunu yürütmekten sorumludur. Bu hizmet, şablonları başlatma sırasında yükler ve işlem devam ettiği sürece bunları bellekte tutar. Bu nedenle, bir şablonda yapılan herhangi bir değişiklik, değişikliklerin uygulanabilmesi için 3CX hizmetinin yeniden başlatılmasını gerektirir.

Gerçek aramalar yapmadan bir şablonu hata ayıklamak için 3CX Konsolu > Settings > CRM İntegration sayfasındaki Test düğmesini kullanın.

Ayrıca Bakınız

• CRM Entegrasyon Sihirbazını kullanarak bir CRM'i entegre etme 
• Bitrix24 CRM Entegrasyonu 
• ConnectWise CRM Entegrasyonu 
• Freshdesk entegrasyonu 
• Jetpack CRM Entegrasyonu 
• Zendesk CRM Entegrasyonu 
• Microsoft SQL Server, MySQL, PostgreSQL Veritabanı Entegrasyonu 

Son Güncelleme

Bu belge en son 17 Ağustos 2024'te güncellendi

https://www.3cx.com.tr/docs/crm-template-xml-aciklamasi/