Skip to main content

Dev Studio

Les applications Pega Platform™, robustes et adaptées aux entreprises, reposent sur la coopération entre deux principaux groupes de développeurs d’applications.  Les experts en domaine (Business Analysts, Citizen Developers et développeurs front-end) fournissent de précieux renseignements sur les processus et les besoins des utilisateurs. Les experts en implémentation (System Architects, développeurs full-stack, administrateurs de bases de données et administrateurs sécurité) fournissent l’expertise nécessaire pour traiter les cas d’usage critiques qui nécessitent des configurations complexes.

Dans App Studio, les experts en domaine peuvent accéder aux fonctionnalités de base du développement d'applications (conception de dossier [Case design], gestion des données et expérience utilisateur) et appliquer leurs connaissances pour améliorer les développements réalisés. Pour permettre la configuration avancée des règles dans les applications, Pega Platform fournit aux experts en implémentation un deuxième environnement de développement, Dev Studio. Dans Dev Studio, les experts en implémentation accèdent directement aux formulaires de règles pour répondre aux besoins de configuration complexes ou moins courants. De plus, Dev Studio fournit des fonctionnalités pour configurer les autorisations de sécurité et les contrôles d'accès, gérer les règles qui favorisent la réutilisation et répondre aux limites de performance d'une application. En fournissant deux environnements de développement, Pega Platform accompagne chaque groupe de développeurs d'applications avec un environnement adapté à leur niveau de compétence et optimisé pour les tâches qu'ils effectuent.

Reportez-vous aux numéros dans l'image suivante pour étudier certaines des options disponibles pour les contrats de niveau de service (SLA) dans Dev Studio, qui vont au-delà de la configuration de base d'objectif et d'échéance disponible dans App Studio :

  1. Comportement d’initialisation : Dans Dev Studio, personnalisez l’urgence (Urgency) initiale d’un SLA et retardez le début de l’objectif (goal) et de l’échéance (deadline) si la tâche (Assignment) est en attente avant d’être envoyée à une Worklist ou une Work Queue.
  2. Longueur d’intervalle variable : Dans Dev Studio, appliquez des durées d’intervalle programmatiques plutôt qu’explicites pour ajuster le comportement du SLA au cas par cas.
  3. Ajustement de l’intervalle d'objectif et de l’urgence : Options d’intervalle d'objectif du SLA configurables dans App Studio.
  4. Prise en compte des jours ouvrables : Dans Dev Studio, excluez les jours non ouvrables du calcul des intervalles des SLA pour tenir compte des jours fériés et des week-ends.
  5. Mesures supplémentaires d’escalade : Dans Dev Studio, configurez des options d’escalade autres que les notifications, comme réattribuer une tâche ou clôturer un dossier.
SLA rule in Dev Studio

Vérifiez vos connaissances avec l’interaction suivante :

Co-développer des solutions

Les Business Analysts et les Citizen Developers comprennent les besoins métiers. Les System Architects comprennent les capacités de Pega Platform. Pour aider ces deux groupes à travailler ensemble, Pega Platform permet une approche de co-développement qui prend en compte les forces de chaque groupe. Cette approche de co-développement permet aux Business Analysts et aux Citizen Developers d'être les membres clés d'une équipe de développement, et tire parti de leurs connaissances pour concevoir de meilleurs processus métier. En travaillant ensemble, les experts en domaine et les experts en implémentation sont à même de créer de meilleures solutions plus rapidement.

Reportez-vous aux numéros dans l’image suivante pour étudier comment un Business Analyst et un System Architect peuvent travailler ensemble pour concevoir une expérience utilisateur positive lorsqu’il s’agit de communiquer une adresse de livraison pour une commande :

  1. Business Analyst : un Business Analyst conçoit les vues (Views) dans App Studio pour saisir l’adresse de facturation et de livraison d’une commande. Les utilisateurs doivent saisir l’adresse de livraison manuellement, même si celle-ci correspond à l’adresse de facturation.
  2. System Architect : un System Architect ajoute une fonctionnalité pour copier automatiquement l’adresse de facturation vers l’adresse de livraison à la demande de l’utilisateur. En outre, le System Architect crée des dossiers test pour s’assurer que la fonctionnalité marche comme prévu et pour identifier les erreurs de régression dans les versions futures de l’application.
  3. Utilisateur (User) : au moment du paiement, un utilisateur coche la case sur la vue complétée pour expédier la commande à son adresse de facturation.
Co-developing solutions diagram

Promouvoir la réutilisation dans l’ensemble de l’organisation

Dans App Studio, les développeurs configurent des règles telles que les processus (Process), les vues (Views), la correspondance et les niveaux de service pour un seul type de dossier (Case Type). Dans Dev Studio, les développeurs accèdent à toutes les couches d'une application et peuvent étendre la portée de la règle d'un seul type de dossier à une application, une division ou même l'organisation entière pour créer une bibliothèque de règles standard et réutilisables. Les Citizen Developers et les Business Analysts peuvent utiliser ces règles testées et éprouvées pour réduire le temps de développement des versions ultérieures.

Reporez-vous aux numéros dans l'image suivante pour examiner comment un System Architect peut étendre la portée d'un processus de validation afin d'améliorer la qualité des applications et de réduire le time-to-market en permettant à un Citizen Developer de réutiliser le processus dans d'autres applications :

  1. Concevoir un processus de validation : À l’aide d’App Studio, un Business Analyst conçoit un processus de validation des déclarations de sinistre dans le cadre d’une application de gestion de polices d’assurance habitation.
  2. Étendre le processus : Étant donné que le processus de validation est uniforme pour de nombreux types de produits d’assurance destinés aux particuliers, un System Architect étend la portée du processus à l’ensemble de la division particuliers à l’aide de Dev Studio.
  3. Réutiliser le processus : À l’aide d’App Studio, les Business Analysts réutilisent le processus de validation dans les applications de gestion des polices d’assurance voyage et automobile, ce qui réduit le time-to-market et améliore la qualité des applications.
Promote reuse in Dev Studio

Passer d’un studio à l’autre

Les développeurs d'applications peuvent basculer entre App Studio et Dev Studio si nécessaire pour configurer le comportement des règles. Le coin supérieur gauche de chaque studio contient un menu énumérant tous les studios disponibles pour l’utilisateur. Pour passer à un autre studio, sélectionnez le nom du studio dans le menu.

Picker control for choosing between studios

De plus, depuis App Studio, vous pouvez ouvrir des règles spécifiques dans Dev Studio. Par exemple, après avoir configuré un objectif (goal) et une échéance (deadline) dans App Studio, vous pouvez ouvrir l’enregistrement (record) de SLA sous-jacent dans Dev Studio.

Example of a service level goal with a link to Dev Studio

Différences de dénomination entre les studios

Dans Dev Studio, les développeurs peuvent accéder aux règles créées par les Citizen Developers, les Business Analysts et les développeurs front-end dans App Studio, bien que ces règles portent souvent des noms différents. Le tableau suivant illustre certains éléments communs d’App Studio et les différents noms utilisés pour ces éléments dans Dev Studio.

App Studio Dev Studio
Champ / Field Propriété / Property
Objectif et échéance / Goal and deadline Contrat de niveau de service / Service Level Agreement (SLA)
Utilisateur / User Opérateur / Operator
Equipe / Team Groupe de travail / Work Group
Note: Par exemple, dans App Studio, vous ajoutez fields aux modèles de données (Data Model) et aux vues (View). Le système crée une property correspondante que vous pouvez modifier dans Dev Studio. Pour plus d’informations, consultez Extending a Data Model for a Case. Pour en savoir plus sur les différences terminologiques entre les deux studios, reportez-vous à la rubrique Differences in naming between App Studio and Dev Studio.

Vérifiez vos connaissances avec l’interaction suivante :


This Topic is available in the following Modules:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice