Guide développeur de l’API ouverte pour la commande de service
Utilisez l’API ouverte de commande de service pour créer, mettre à jour et récupérer des informations de commande de service.
Ce guide développeur fournit des informations sur la façon d’étendre le Commande de service API ouverte pour effectuer diverses personnalisations.
Extension de l’API ouverte de la commande de service
L’API ouverte de commande de service peut être étendue en modifiant des script includes.
- TMFServiceOrderAPIUtil : contient des fonctions pour gérer les requêtes POST.
- TMFServiceOrderGetAPIUtil : contient des fonctions pour gérer les demandes GET.
- ServiceOrderExtensionOOB : contient des fonctions d’aide qui prennent en charge les fonctions dans TMFServiceOrderAPIUtil et TMFServiceOrderGetAPIUtil.
- ServiceOrderProcessor : fichier de script include vide. Utilisez ce fichier pour définir toutes les fonctions que vous souhaitez remplacer par ServiceOrderExtensionOOB.
Étendez l’API ouverte de commande de service pour effectuer les personnalisations suivantes.
Paramètres requis
Pour modifier les paramètres de corps de demande requis ou non pour créer une commande de service, remplacez la fonction getServiceOrderSchema() contenue dans le script include ServiceOrderExtensionOOB .
La fonction getServiceOrderSchema() lit le schéma à partir du script include 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 contourner getServiceOrderSchema() pour lire un nouveau schéma. Pour remplacer getServiceOrderSchema(), écrivez une fonction du même nom dans le script include ServiceOrderProcessor . La nouvelle fonction de 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 constantes. // 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
true par défaut.validatePostRequest()- Appelé parprocessPostOrder()dans TMFServiceOrderAPIUtil.validateServiceObj(): appelé parprocessPostOrder()dans TMFServiceOrderAPIUtil.validateRelatedPartyObj(): appelé parprocessPostOrder()dans TMFServiceOrderAPIUtil.validateGetRequest(): appelée parprocessGetOrder()dans TMFServiceOrderGetAPIUtil.
la valeur false, elle arrête le fonctionnement de l’API. Pour appliquer une validation personnalisée, remplacez les fonctions d’aide 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 Service Order Open. La logique des nouvelles ressources REST scriptées doit être cohérente avec les opérations existantes. Définissez les fonctions pour les nouvelles opérations dans un nouveau script include.
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 des 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'
});