La Revolución!! El poder de @Invocable – Spring 15 (Parte 1)

Entre las cositas que nos trae esta nueva reléase, Spring ’15, una de las que más me gusta es la posibilidad de invocar métodos apex desde Process builder.

Pero lo que me gusta aún más, es que estos métodos no solamente se pueden invocar/ ejecutar desde Process Builder sino que también los puedes invocar y ejecutar usando REST APIs

Pues vamos a ver cómos se puede hacer, que debemos tener en cuenta.

Lo primero es implementar la clase que contiene nuestro @InvocableMethod. Dicha clase es una clase normal que puede ser tanto pública o global pero debe ser externa.

Apunte: Cuando estaba probando la funcionalidad en una org pre-release me dio este error << We can’t find an action with the name and action type that you specified.>> Cambie la clase a global, guardé , volví a editar cambié de nuevo a pública y ya no me ha vuelto a pasar.

Una vez tenemos definida nuestra clase , pasamos a implementar los métodos que compondrán esta.

Apunte: De nuevo algo a tener en cuenta es que solamente podemos tener un método con la notación @InvocableMethod

¿Cómo debemos definir nuestro método invocable?

Tenemos varias opciones, pero veamos lo que ocurre en cada una de ellas:

```
@InvocableMethod public static void myInvocableMethod() 
```
- Desde Process Builder: Process builder tendrá conocimiento del método, y lo invocara cuando todo cumpla los requistos que se han especificado en dicho proceso.
- REST calls: Y como comentaba estos métodos también podrán ejecutarse y consultarse a través de REST API, pero para ello necesitas estar definidos de una forma específica. Con lo que ¡OJO! , en esta definición no podremos ejecutar el metodo usando llamadas REST (POST call) . A través de REST API solamente podremos consultarlo ,(GET call) nos devolverá todos los metadatos del método. Algo como esto: ( si os fijaies inputs se refiere a los parametros que se le pasan al metodo y output lo que el metodo devuelve, en este caso nada )
```
{ "description" : null,
   "inputs" : [ ],
    "label" : "InvocableClass",
    "name" : "InvocableClass",
    "outputs" : [ ],
    "standard" : false,
    "targetEntityName" : null,
    "type" : "APEX" }
```

```
 @InvocableMethod public static List<String> myInvocableMethod() 
```
- Desde Process Builder: de nuevo Process Builder vuelver a reconocerlo y ejecutarlo,
- Desde REST API: aunque si intentamos ejecutarlo a través de Rest API este no será ejecutado, sin embargo como antes tendremos la posibilidad de conseguir los metadatos.
- Apunte: También me gustaría comentar que aunque he puesto como ejemplo List< String> , la lista puede ser de cualquier tipo. Pero eso si , necesita ser List , no puede ser directamente un tipo de dato simple, lo que quiero decir es que no es posible devolver un simple String, o quizás un Account… debe ser List<String> , List<Account>… Al final del post podreis encontrar todos los tipos permitidos tanto de entrada como de salida.
```
 @InvocableMethod public static void myInvocableMethod(List<String> myListParam) 
```
- Desde Process Builder: de nuevo podemos decir que Process builder es feliz ejecutando este método, y desde process builder podemos establecer el valor del parámetro myList. Lo interesante en este punto es que aunque process builder parece que nos deja añadir más de un parámetro veremos que no está permitido. Y de igual forma si en la definición intentamos añadir mas de un parámetro de nuevo nos darás un error porque no más de un parámetro es permitido. Aquí quizás podríamos ser un poco críticos desde el punto de vista de UX, ¿por qué me dejas añadir mas de un parámetro en UI si mas tarde no me permites guardar? … bueno podríamos argumentar varias razones, pero realmente funciona igual que cuando intentamos implementar el método con mas de un parámetro, podemos añadir todos los que queramos pero cuando llega la hora de guardar entonces es cuando salta la validación. ¿Podríamos decir que Process Builder se ha creado con mentalidad de compilador 😀 ? ( ya lo sé una broma mala 😛 )
- REST API: De nuevo podremos como antes obtener los metadatos de este método (GET call) Pero ahora por fin tenemos luz verde!! Se invocará el método, donde la llamada será una llamada POST. Es aquií con esta notacion cuando podemos hacer consultas o crear datos , o invocar otros procesos… El cuerpo de esta llamada será algo como esto:

        {"inputs" : [ {"myListParam" : "param1"} , {"myListParam" : "param2"} ]}

Luego para poder llamar a estos metodo usando REST APIs necesitamos definir el metodo con un parametro de entrada , sino este no seraá invocado/ejecutado tras la llamada.

Lo mejor para el final, quizás lo que mas me atrae de esta funcionalidad es que dentro de los @InvocableMethod podemos hacer llamadas a APIs de otros productos, con lo que las integraciones con otros productos, aplicaciones será mucho más facil. De hecho quizas es un futuro a una nueva forma de definir e implimentar las APIs que compondran los productos para que vivan o sean usadas dentro de @InvocableMethods.

Para terminar, he aquí el ejemplo que podría resumir este post:


global class CreateInvoicesUsingInvocable {
    @InvocableMethod
    public static List<Invoice__c> InsertInvoices(List <String> vendors) {

       List<Invoice__c> myInvoices = new List<Invoice__c>();
       for (String  invVendor: vendors)
       {
         Invoice__c inv = new Invoice__c(Vendor__c = invVendor);
         myInvoices.add(inv) ;
       }

       insert myInvoices;

       return myInvoices;
    }

  //other methods 
}

Para probar esto mismos desde workbench , usamos una llamada REST – POST

EndPoint: /services/data/v33.0/actions/custom/apex/CreateInvoicesUsingInvocable
Method : Post
Request Body:


{
"inputs" : [ {
"vendors" : "v1"
},
{
"vendors" : "v2"
}
]
}

Lo mejor para el final, lo que más más me ha gustado es que dentro de este @InvocableMethod podemos llamar a “terceras” APIs, con lo cual el proceso de integración podría ser mucho mucho mas sencillo.

¡La revolución! Podemos empezar a pensar en una nueva forma de implementar las APIs de nuestro productos para que estas sean usadas dentro de los nuevos y potentes @InvocableMethod , y a la vez llamadas a través de Process builder para hacer la vida más fácil a Consultores, Administradores…

Pero además para desarrolladores de aplicaciones externas que pueden llamar a estos “Cool Methods” 😀

Para terminar una pequeña lista a tener en cuenta.

Solamente 1 metodod the tipo @InvocableMetod se permite por clase
Estos métodos no se pueden ejecutar desde un Trigger
@InvocableMethod tiene que ser static public o static global, y debe estar definido en una clase externa.
Solamente 1 parametro de entrada es permitido y el tipo de este parámetro debe ser :
1. Lista de datos primitivos o lista de listas de datos primitivos. El tipo Object no se permite.
2. Lista de tipos Apex ( clases , datos definidos por el usuario ) que contengan la notación @InvocableVariable.
  1. Si la clase que se pasa por parámetro dentro de la lista no continue ninguna variable con esta notación, no se permite
```
public with sharing class MyClass{

     @InvocableVariable
     public String myVar;
}

public with sharing class MyInvocableClass{

    @InvocableMethod

    public static void myInvocable( List<MyClass> myclasses )

    {

      //Do something

    }
}
```
3. List<SObject> no se permite, pero cuando no nos referimos al genérico SObject, entonces sí podemos , List<Account> sí esta permitido.

Si el método nos devuelve algo, debe ser de tipo:
1. Lista de primitivos, pero no el genérico Object
2. Lista de un tipo especifico de SObject, como por ejemplo List<Account> pero no el genérico List<SObject>
3. Lista de objetos definidos por el usuario, Apex type, como clases … pero no el genérico List<Object> De nuevo estas clases deben de tener al menos una variable con la notación @InvocableVariable
Y algo muy bueno!! Se pueden usar @InvocableMethod dentro de packetes!! Ahora sí una vez dentro del paquete para versiones posteriores, este método no podrá ser borrado de dicho paquete.

Algunos links que podrian ser de utilidad:

– Un gran y divertido ejemplo de uso por Andy

– Stackexchange 1

– Stackexchange 2

– Invocable Actions

– Invocable Methods Anotation

– REST API

-Process Builder