Bienvenido a PointMind

PointMind
0
  • No hay productos en el carrito.
  • Inicio
  • Nosotros
  • Servicios
    • Infraestructura Tecnologica
    • Administración de Identidades
    • Gestión de Procesos de Negocio – BPM
    • Gestión de la Información
    • Tercerización de Procesos
  • Blog
  • Contacto
Introducción a Apiary y como crear APIs

Introducción a Apiary y como crear APIs

Cómo configurar el componente de autotraducción en Oracle IBCS

Cómo configurar el componente de autotraducción en Oracle IBCS

Caracteristicas de Oracle Process Cloud Service

Caracteristicas de Oracle Process Cloud Service

PointMind

Home

Autor: administrador

17 Nov

Introducción a Apiary y como crear APIs

by administrador | with 0 Comment | in API, Cloud, Consultoria, Desarrollo, Oracle Bots, SOA
Introducción a Apiary y como crear APIs

Introducción a Apiary y como crear APIs

La Interfaz de Programación de Aplicaciones (API) tiene operaciones que pueden ser consumidas por la aplicación. Comprendamos con la ayuda de un escenario donde las API desempeñan un papel. Supongamos que hay una compañía de taxis que desea permitir la reserva de un taxi a través de una aplicación móvil o un sitio web. Ahora, esta característica u operación debe estar expuesta para que pueda ser utilizada por los clientes que están desarrollando los sitios web o una aplicación móvil. La operación para exponer la reserva de la cabina tendrá algunos parámetros de entrada y salida. Estas operaciones son un contrato entre las personas que crean la API y las personas que consumen la API. En este artículo, veremos cómo Apiary juega un papel en el diseño de API, haremos una introducción a Apiary y como crear APIs con esta plataforma adquirida por Oracle recientemente

Aquí, veremos cómo Apiary puede ayudar a diseñar API rápidamente y cómo puede ayudar a superar algunos problemas comunes de implementación e integración.

¿Qué es Apiary?

Apiary nos permite primero crear el diseño de una API y luego implementarlo. Apiary ayuda a crear un marco simulado del API y también genera su documentación con bastante rapidez. En el diseño del API, especificamos las operaciones compatibles, los parámetros de entrada para las operaciones y también el modelo de datos de salida; en otras palabras, salida JSON. Estas APIs simuladas se pueden consumir en las aplicaciones para ver si el diseño de la API cumple con las necesidades de la aplicación. Con Apiary, las modificaciones se pueden modificar rápidamente y pueden pasar por varias iteraciones muy rápidamente sin escribir ningún código.

¿Por qué Apiary?

Generalmente, si deseamos crear una API, primero definimos el esquema para la entrada y la salida. Luego, definimos las operaciones para devolver los datos; en otras palabras, implementamos una solución mínima antes de que pueda integrarse.

Con Apiary, las API se pueden diseñar (o declarar) donde se pueden burlar los datos de entrada y de salida. Los datos simulados representan el resultado que devolverá la acción. Esta API simulada y los datos se pueden integrar y probar para verificar que cumplan con los requisitos de la aplicación. Estos cambios pueden realizarse sin ningún esfuerzo de codificación.

Esto también ayuda cuando hay varios equipos trabajando simultáneamente. Un equipo trabaja en la implementación de API y otros equipos consumen las API. Una vez que se finaliza el contrato, ambos equipos pueden trabajar de forma independiente.

Como Usar Apiary

Para usar Apiary para diseñar API, haga clic en ‘Apiary’. Use su cuenta de GitHub para iniciar el diseño de la API. Una vez iniciada la sesión, la UI ofrece una opción para crear una nueva API. Especifique un nombre y haga clic en el botón «Crear API». Crea los métodos API simulados; por ejemplo, enumerar notas, crear notas, recuperar un nodo por ID, etc. También especifica los diferentes métodos HTTP que se utilizan; en otras palabras, GET, POST, DELETE, y así sucesivamente.

Comprendamos las diferentes secciones de la declaración API.

 1. FORMAT: 2A
 2. # testAPI
 3. Notes API is a *short texts saving* service similar
    to its physical paper presence on your table.
 4. # Group Notes
 5. Notes related resources of the **Notes API**
 6. ## Notes Collection [/notes]
 7. ### List all Notes [GET]
 8. + Response 200 (application/json)
 9.    [{
10.       "id": 1, "title": "Jogging in park"
11.    }, {
12.       "id": 2, "title":
          "Pick-up posters from post-office"
13.    }]

Una API de ejemplo se declaró en el fragmento de código anterior, y la salida de la documentación de esta se muestra en la Figura 1.

Figura 1: Salida de la API
Figura 1: Salida de la API
  • Linea 1: FORMAT specifies the version of the API.
  • Linea 2: En #testAPI, ‘#’ define el encabezado en la documentación. El número de símbolos # define los subtítulos; en otras palabras, ## & ### en la línea 6 y 7 define los subtítulos.
  • Linea 4: # Group Notes define un grupo llamado ‘Notes’.
  • Linea 6: define el subtítulo y la URL para acceder a la API.
  • Linea 7: especifica el método HTTP y el nombre de la acción. En este caso, el método HTTP es ‘GET’ y el nombre de la acción es’Notes’.
  • Linea 8: especifica que la acción devuelve un código de estado de respuesta como 200 y los datos JSON.

Esto explica cómo las API simuladas devuelven datos. La pantalla en la Figura 1 muestra la documentación creada para el diseño de la API.

También es compatible con otros verbos como ‘POST’ y ‘DELETE’. Un ejemplo para el ‘POST’ es:

1. ### Create a Note [POST]
2. + Request (application/json)
3. { "title": "Buy cheese and bread for
   breakfast." }
4. + Response 201 (application/json)
5. { "id": 3, "title": "Buy cheese and
   bread for breakfast." }

En la línea 1, se define el método HTTP «POST». En este ejemplo, toma un parámetro de solicitud llamado ‘title’ y devuelve un código de respuesta 201 y datos JSON compuestos de id y títle.

Resumen

Con Apiary, el enfoque de «design API first» puede implementarse donde los parámetros de entrada/salida se pueden finalizar y las maquetas se pueden probar incluso antes de que se implemente. Esto mejorará la coordinación entre los equipos y también la productividad.

 

27 Oct

Cómo configurar el componente de autotraducción en Oracle IBCS

by administrador | with 0 Comment | in Cloud, Consultoria, Oracle Bots
Cómo configurar el componente de autotraducción en Oracle IBCS

Cómo configurar el componente de autotraducción en Oracle IBCS

Por defecto el servicio de Oracle Intelligent Bot Cloud Service (Oracle IBCS ) viene con un motor NLP configurado en ingles, lo que hacia dificil la implementacion de chatbots en otros lenguajes. En la última versión de Oracle IBCS, Oracle adiciono un servicio de traducción al que se puede llamar antes de resolver el intent por parte del usuario. Este post se enfoca en cómo configurar el componente de autotraducción en Oracle IBCS, para facilitar la implementación en otros idiomas de chatbots.

Para comenzar una conversación con el bot en el idioma del usuario, necesitamos usar el componente de autotraducción.

Como se puede  ver en la documentación de Oracle:

Autotranslation uses services like Microsoft Translator and the Google Translation API to enable the built-in components like System.Text and System.Output to output their prompts in the user’s language.

Como usar el componente de auto traducción?

Primero tenemos que configurar el servicio de traducción que usaremos

Configuración del Servicio de Traduccion en IBCS

Aquí se esta usando la API de traducción de Google, consulte este tutorial  sobre cómo configurar su API de Google Translate.

Segundo  hacer clic en configuración de su bot y elegir la pestaña General, luego elija el servicio de traducción de la siguiente manera:

Configuración del bot para autotraduccion
Tercero. Ahora que está listo para configurar el flujo del bot, consulte el siguiente código de ejemplo tomado de los documentos de Oracle IBCS aquí:

metadata:
 platformVersion: "1.0"
main: true
name: "AutoTranslatePizzaBot"
parameters:
 age: 18
context:
 variables:
 size: "PizzaSize"
 type: "PizzaType"
 crust: "PizzaCrust"
 iResult: "nlpresult"
 autoTranslate: "boolean" 
 translated: "string"
states:
 setAutoTranslate:
 component: "System.SetVariable"
 properties:
 variable: "autoTranslate"
 value: true
 transitions: {}
 detect:
 component: "System.DetectLanguage"
 properties: {}
 transitions: {}
 translate:
 component: "System.TranslateInput"
 properties:
 variable: "translated"
 transitions: {}
 intent:
 component: "System.Intent"
 properties:
 variable: "iResult"
 sourceVariable: "translated" 
 confidenceThreshold: 0.4

 

Como puede ver, lo primero que debe hacer es agregar dos variables como las siguientes:

autoTranslate: “boolean” 
translated: “string"

La variable autoTranslate es booleana y la variable traslated es una cadena.

Entonces se llama al primer estado en el flujo del bot (setAutoTranslate) de la siguiente manera:

setAutoTranslate:
 component: “System.SetVariable”
 properties:
 variable: “autoTranslate”
 value: true
 transitions: {}

el cual está utilizando el componente integrado System.SetVariable para establecer la variable autoTranslate en true para habilitar la traducción.

El siguiente estado es detectar qué está usando el componente integrado System.DetectLanguage. Usamos este componente para detectar el idioma del usuario.

detect:
 component: “System.DetectLanguage”
 properties: {}
 transitions: {}

El siguiente estado es translate, y estamos usando el componente incorporado System.TranslateInput aquí, usamos este componente para traducir explícitamente la entrada del usuario:

translate:
 component: “System.TranslateInput”
 properties:
 variable: “translated”
 transitions: {}

El componente System.TranslateInput obtendrá la entrada del usuario y llamará al servicio de traducción para traducir la entrada al idioma inglés y almacenar la traducción en la variable traducida que definimos anteriormente en el contexto.

Ahora, después de la traducción, es el momento de saber cuál es la intent del usuario, así que llamamos al System.intent  para que la variable traducida vaya al Motor NLP y obtenga el intent del usuario:

intent:
 component: “System.Intent”
 properties:
 variable: “iResult”
 sourceVariable: “translated” 
 confidenceThreshold: 0.4

Aquí el estado de intención es usar el componente System.Intent, la propiedad sourceVariable está tomando la entrada de la variable translated y devolverá el resultado del nlp y lo almacenará en la variable iResult que se define con la propiedad variable.

 

 

Tagged articulos, Consultoria
13 May

Oracle BPM en Cloud

by administrador | with 0 Comment | in BPM, Consultoria

En los últimos años Oracle Coporation ha realizado bastantes esfuerzos en posicionar sus esquemas de cloud en los diferentes productos de su stack tecnológico, El mensaje enviado por Oracle entonces es: «Cloud«. Frente a este reto que se enfrentan los clientes, estos tratan de comparar y aclarar las diferencias con los productos «onPremise» que poseen o desean adquirir para tomar decisiones al respecto, al comparar estas soluciones en la nube con sus predecesores locales, ellos podría pensar: «¿cuál es la diferencia real?» Esta entrada se enfocara en un componente del stack tecnológico Oracle: la gestión de los procesos, para ello vamos a analizar el Oracle BPM en Cloud.  Se tratara de mostrar la diferencia entre Oracle BPM12c y Oracle Process Cloud Service (PCS).  PCS es la nueva versión basada en la nube de Oracle BPM ( la cual es la version onPremise ).

Arquitectura

Aunque PCS se basa en el mismo software y motor que BPM 12c hay una gran diferencia real en la arquitectura de ambas soluciones.

Aspecto de tiempo de ejecución

El mayor cambio arquitectónico es, por supuesto, el movimiento hacia la nube. La nube permite que PCS sea más escalable. La infraestructura, la seguridad y la administración de servidores son administrados por Oracle. Esto reduce la cantidad de conocimiento requerido por la organización para gestionar la funcionalidad de la plataforma. Las actualizaciones y parches de PCS también serán ejecutados por Oracle. Así que obtendrá «incluida» esta funcionalidad extra cada tres meses.

Interfaz de usuario

En BPM12c  al igual que en BPM 11g  necesitara usar Oracle ADF para el desarrollo de sus pantallas y Oracle BAM para el tablero de mandos. En Process Cloud Service, el desarrollo de los formularios y cuadros de mando se ha estandarizado y se ha trasladado al producto.

Desarrollo

En BPM12c se requiere de un entorno de desarrollo local JDeveloper. En PCS puede construir todo en la nube. La gran diferencia es también que el desarrollo en PCS requiere menos conocimiento técnico y puede ser hecho por una persona, mientras que el desarrollo de BPM y ADF es a menudo realizado por diferentes personas.

Capacidades

Al comparar las capacidades de BPM 12c y PCS todavía se puede ver que PCS es un producto nuevo, y por consiguiente posee menos funcionalidades que BPM 12c y se puede comparar mejor con BPM 11g.

Por ejemplo, la gestión de casos ( case management ) es una funcionalidad presente en BPM 12c y no en PCS. otra capacidad es la de permitir al usuario empresarial crear modelos estratégicos con KPI, que puedan ser mapeados a procesos.

En el ámbito de desarrollo sobre BPM, Oracle BAM y ADF  proporcionan a los desarrolladores la oportunidad de crear paneles de control  y aplicaciones de frontend mas personalizados.

Oracle PCS todavia es  muy básico y estandarizado ( vea las características de PCS ) . La gran diferencia está en la ventaja que PCS tiene de ciclos de liberación de release mucho más rápidos que incrementaran las capacidades del producto, PCS tendrá una actualización importante cada 3 meses y cuando sea necesario actualizaciones adicionales mensuales.

El foco del equipo de desarrollo de Oracle  está en PCS ya que como se indicaba  anteriormente la nube es el futuro de esta línea de productos.

Velocidad de desarrollo

Al comparar Business Process Management 12c y PCS enfocados en la velocidad de desarrollo la mayor diferencia es la complejidad. En PCS el foco está realmente en el desarrollo no técnico de los procesos. La mayoría de las cosas como crear formularios, asignaciones de webservices y procesos se realizan con arrastrar y soltar. En BPM 12c este topico es más complejo, ya que los clientes a menudo eligen formularios ADF personalizados acercándose a los requerimientos de los clientes, pero por supuesto reducen la velocidad de desarrollo en comparación con PCS, ya que están creando funcionalidades que ya están disponibles en PCS.

Precios y costes de mantenimiento

Ambos productos tienen diferentes modelos de precios, pero en general se puede decir PCS es mucho más barato cuando no se tiene bastantes usuarios. Con un precio de $USD100 por usuario por mes y un mínimo de 10 usuarios, puede tener PCS en funcionamiento por sólo $USD12000 por año. El precio para BPM 12c se basa en la CPU sobre la que se ejecuta el producto y a menudo cuesta 4 veces más que PCS por año. Sin embargo, no hay limitación en la cantidad de usuarios.

Cuando se utiliza PCS con usuarios que sólo utilizan la aplicación una vez al año se pueden hacer acuerdos especiales sobre precios con Oracle, pero es un caso específico.

Conclusión

Al comparar PCS y BPM 12c se puede ver que la nube realmente está haciendo la diferencia.

A pesar de que todavía hay menos funcionalidad disponible en PCS, la disponibilidad en la nube le brinda la escalabilidad que necesita y la nueva funcionalidad sera entregada cada pocos meses. Así que si realmente necesita la funcionalidad adicional que BPM 12c le proporciona, entonces debería elegir BPM 12c. De lo contrario, debe comenzar con el uso de las funcionalidades básicas de PCS y usted será capaz de hacer más y más utilizando Oracle BPM en Cloud.

PointMind le puede ayudar a su organización a ganar eficiencia y control sobre los procesos de esta  de una manera rápida y segura, en esquemas de BPM 12c o PCS.  Contáctenos

 

Tagged Procedimientos

Entradas recientes

  • Introducción a Apiary y como crear APIs
  • Cómo configurar el componente de autotraducción en Oracle IBCS
  • Caracteristicas de Oracle Process Cloud Service
  • Características Centrales de Oracle SOA Suite 12c
  • Como Instalar Oracle Webservices Manager 11g

Comentarios recientes

    Archivos

    • noviembre 2017
    • octubre 2017
    • noviembre 2016
    • junio 2016
    • mayo 2016
    • abril 2016
    • febrero 2016

    Categorías

    • Administracion
    • API
    • BPM
    • Cloud
    • Consultoria
    • Desarrollo
    • Educacion
    • Infraestructura Tecnologica
    • Oracle Bots
    • Oracle Web Services Manager
    • SOA
    • Weblogic

    Meta

    • Acceder
    • Feed de entradas
    • Feed de comentarios
    • WordPress.org

    Acerca de Nosotros

    Contactenos

    Trabajamos duro, nos capacitamos constantemente , somos ambiciosos, buscamos retos y estamos aún más comprometidos cuando los proyectos son complejos y desafiantes

    Contacto

    Calle 105 No 54 -67

    571.4746888

    Conectate con Nosotros

    Derechos Reservados Pointmind
    • Inicio
    • Nosotros
    • Servicios
      • Infraestructura Tecnologica
      • Administración de Identidades
      • Gestión de Procesos de Negocio – BPM
      • Gestión de la Información
      • Tercerización de Procesos
    • Blog
    • Contacto