Guide du développeur Open API de la commande de service
Utilisez l’API Service Order Open pour créer, mettre à jour et récupérer des informations sur les commandes de services.
Ce guide du développeur fournit des informations sur la façon d’étendre le API ouverte de commande de service pour effectuer diverses personnalisations.
Extension de l’API ouverte de l’ordre de service
L’API Service Order Open peut être étendue en modifiant les includes de script.
- TMFServiceOrderAPIUtil : contient des fonctions pour gérer les demandes POST.
- TMFServiceOrderGetAPIUtil : contient des fonctions pour gérer les demandes GET.
- ServiceOrderExtensionOOB : contient des fonctions d’assistance qui prennent en charge les fonctions dans TMFServiceOrderAPIUtil et TMFServiceOrderGetAPIUtil.
- ServiceOrderProcessor : fichier d’include de script vide. Utilisez ce fichier pour définir toutes les fonctions que vous souhaitez remplacer à partir de ServiceOrderExtensionOOB.
Étendez l’API Service Order Open pour effectuer les personnalisations suivantes.
Paramètres requis
Pour modifier les paramètres du corps de la demande requis ou non pour créer une commande de service, remplacez la fonction getServiceOrderSchema() contenue dans l’include de script ServiceOrderExtensionOOB .
La fonction getServiceOrderSchema() lit le schéma à partir de l’include de script TMFOrderAPIConstants . TMFOrderAPIConstants est protégé et ne peut pas être modifié, vous ne pouvez donc pas simplement mettre à jour le schéma. Au lieu de cela, un nouveau schéma doit être lu à partir d’un fichier différent. Vous pouvez remplacer getServiceOrderSchema() pour lire un nouveau schéma. Pour remplacer getServiceOrderSchema(), écrivez une fonction portant le même nom dans l’include de script ServiceOrderProcessor . La nouvelle fonction dans ServiceOrderProcessor sera appelée par TMFServiceOrderAPIUtil pour remplacer la fonction getServiceOrderSchema() par défaut dans ServiceOrderExtensionOOB.
getServiceOrderSchema() renvoie un schéma personnalisé qui est défini dans un nouveau fichier de constante. // ServiceOrderProcessor
var ServiceOrderProcessor = Class.create();
ServiceOrderProcessor.prototype = Object.extendsObject(ServiceOrderExtensionOOB, {
// Define overriding functions here
// Function name and parameters must be identical to the function it overrides
getServiceOrderSchema: function() {
//Define your own custom schema in a new constant file
return JSON.parse(Constants.SCHEMA.CREATE_SERVICE_ORDER);
},
type: 'ServiceOrderProcessor'
});Validation du corps de la demande
la valeur vrai par défaut.validatePostRequest(): appelé parprocessPostOrder()dans TMFServiceOrderAPIUtil.validateServiceObj(): appelé parprocessPostOrder()dans TMFServiceOrderAPIUtil.validateRelatedPartyObj(): appelé parprocessPostOrder()dans TMFServiceOrderAPIUtil.validateGetRequest(): appelé parprocessGetOrder()dans TMFServiceOrderGetAPIUtil.
la valeur faux, elle arrête l’opération d’API. Pour appliquer la validation personnalisée, remplacez les fonctions d’assistance ServiceOrderExtensionOOB en créant des fonctions avec des noms et des paramètres identiques dans ServiceOrderProcessor. Ces nouvelles fonctions ServiceOrderProcessor seront appelées par TMFServiceOrderAPIUtil et TMFServiceOrderGetAPIUtil pour remplacer les fonctions d’assistance ServiceOrderExtensionOOB par défaut.// ServiceOrderProcessor
var ServiceOrderProcessor = Class.create();
ServiceOrderProcessor.prototype = Object.extendsObject(ServiceOrderExtensionOOB, {
// Define overriding functions here
// Function name and parameters must be identical to the function it overrides
validatePostRequest: function(orderObject, details) {
// Returning false terminates the POST request
// Make sure to push error message in details array in case of error
if (gs.nil(orderObject.serviceOrderItem)) {
details.push(new TMFCommonOrderAPIUtil().getErrorDetailsObj(TMFOrderAPIConstants.MESSAGES.MISSING_ORDER_ITEM, '/'));
return false;
}
return true;
},
type: 'ServiceOrderProcessor'
});Opérations REST supplémentaires
Pour créer des opérations supplémentaires au-delà des opérations GET et POST existantes, créez des ressources REST scriptées supplémentaires pour l’API ouverte de commande de service. La logique des nouvelles ressources REST scriptées doit être cohérente avec les opérations existantes. Définissez des fonctions pour les nouvelles opérations dans un nouvel include de script.
Mappage de champs
Lors de la création d’enregistrements, l’API mappe les paramètres du corps de la demande aux champs d’enregistrement. Lors de la récupération des enregistrements, l’API mappe les champs d’enregistrement aux attributs d’objet de réponse.
transformOrderGr()transformOrdLineItemGr()transformCustLineItmContact()transformOrderItemChar()
transformPostOrderResponse()transformGetOrderResponse()transformServiceObj()transformRelatedPartyCustomerLineItem()transformOrderItemRelationship()transformGetOrdLineItmResponse()transformServiceCharacteristics()transformServiceSpecification()
Personnalisez les mappages de champs pour ajouter et récupérer des données pour des champs supplémentaires, ou pour modifier les mappages par défaut pour les champs. Pour personnaliser les mappages de champs, remplacez les fonctions de mappage ServiceOrderExtensionOOB en créant des fonctions avec des noms et des paramètres identiques dans ServiceOrderProcessor. Ces nouvelles fonctions ServiceOrderProcessor seront utilisées par TMFServiceOrderAPIUtil et TMFServiceOrderGetAPIUtil pour remplacer les fonctions de mappage ServiceOrderExtensionOOB par défaut.
// ServiceOrderProcessor
var ServiceOrderProcessor = Class.create();
ServiceOrderProcessor.prototype = Object.extendsObject(ServiceOrderExtensionOOB, {
// Define overriding functions here
// Function name and parameters must be identical to the function it overrides
transformOrderGr: function(requestObject, orderGr) {
orderGr.external_id = requestObject.externalId;
return orderGr;
},
transformPostOrderResponse: function(orderObject, orderGr) {
orderObject.id = orderGr.getValue('sys_id');
return orderObject;
},
type: 'ServiceOrderProcessor'
});