En el diseñador de procesos de negocio de Bitrix24 existe la acción «Código PHP», que ejecuta código arbitrario dentro del proceso. Solo está disponible en la versión on-premise: en Bitrix24 en la nube esa acción no existe en ninguna tarifa. Sin embargo, las tareas típicas para las que se añade PHP a un proceso —petición a una API externa, análisis de la respuesta, extracción de texto, condición compuesta— se montan en la nube con robots ya listos. Veamos dónde está la frontera y con qué se sustituye cada escenario.

¿Dónde está disponible la acción «Código PHP» y por qué no existe en la nube?

«Código PHP» es una acción de la edición on-premise: dentro de la plantilla se escribe código arbitrario que se ejecuta en el servidor del portal con acceso a la API del núcleo. En la nube el portal funciona sobre la infraestructura compartida de Bitrix24, y la ejecución de código de usuario allí está cerrada: es una limitación de arquitectura, no una cuestión de tarifa ni de un ajuste oculto. Por eso las instrucciones de los foros del tipo «inserta este PHP en el proceso de negocio» solo sirven para la versión on-premise. Si miramos qué hace en realidad el código en esas plantillas, casi siempre es una de cuatro cosas: acceder a un sistema externo, analizar su respuesta, sacar un trozo de una cadena, tomar una decisión según varias condiciones. Cada bloque se cubre en la nube con un robot aparte; a continuación, uno por escenario.

¿Cómo acceder a una API externa sin PHP?

El robot «Petición HTTP GET/POST» ejecuta la petición directamente desde el proceso de negocio: métodos GET, POST, PUT, PATCH, DELETE y HEAD, cuerpo arbitrario, cabeceras en formato JSON —por ejemplo, Authorization para el token— y un tiempo de espera de 1 a 60 segundos. Devuelve el cuerpo de la respuesta, el código de estado HTTP y un indicador de éxito S/N (código 2xx). Las redirecciones se comprueban en cada paso, el acceso a direcciones internas de la red se bloquea, el cuerpo de la respuesta está limitado a 1 MB; el robot está disponible en las tarifas de pago de Bitrix24. Con esto basta para integraciones del nivel de «pasar los datos de la negociación al sistema de gestión y recoger el estado del pedido». La recepción de datos en sentido inverso, de fuera hacia el portal, se hace mediante webhooks.

¿Cómo analizar la respuesta de una API sin json_decode?

La respuesta de un sistema externo casi siempre es JSON, y en el PHP on-premise venían a continuación un par de líneas con json_decode. En la nube, lo mismo lo hace el robot «Extraer valor de un JSON por ruta»: recibe una cadena JSON y una ruta separada por puntos —data.user.email, items.0.name—, devuelve el valor como cadena, los objetos y los arrays como JSON para un análisis posterior, más un indicador «Ruta encontrada» (S/N). Si el JSON es incorrecto o la ruta no existe, el robot devuelve N: con él, el proceso desvía el error a una rama aparte en lugar de escribir un vacío en el campo de la negociación. La combinación «petición HTTP → extraer valor → escribir en el campo» cubre la mayoría de los escenarios de integración que antes requerían código.

¿Cómo sacar datos de un texto sin preg_match?

El segundo clásico del PHP en los procesos son las expresiones regulares: sacar el número de pedido del asunto de un correo, encontrar enlaces en un comentario, comprobar el formato de una referencia. El robot «Extraer mediante expresión regular» aplica el patrón a la cadena de origen: el patrón se indica sin delimitadores, el cirílico y el unicode se tratan correctamente, y el número del grupo de captura permite devolver no toda la coincidencia, sino una parte concreta, por ejemplo el valor entre paréntesis. Devuelve la primera coincidencia, la lista de todas las coincidencias y un indicador «Encontrado» (S/N). Caso típico: un prospecto creado a partir del correo «Pedido ORD-12345: consulta sobre la entrega»: el patrón ORD-\d+ saca el número y el proceso encuentra la negociación asociada.

¿Cómo sustituir un if con varias condiciones?

El «Condición» estándar del diseñador compara valores, pero una combinación de tres o cuatro comprobaciones convierte la plantilla en una escalera de ramas anidadas: exactamente lo que en on-premise se escondía en tres líneas de código. El robot «Condición compuesta (AND / OR / NOT)» monta la comprobación en un solo paso: hasta cuatro tríos «valor — operador — valor» con lógica AND u OR; entre los operadores hay igualdad, comparación de números, contains, is_empty. Para un anidamiento arbitrario hay un modo JSON con grupos and, or y not. A la salida, un único indicador S/N por el que el proceso se ramifica con un «Condición» normal: la lógica se lee en el diseñador, y no en un código que solo entendía su autor.

¿Cuándo no se puede prescindir de la versión on-premise?

La frontera honesta: los robots cubren los escenarios de integración y de lógica, pero no todo. Si el código debe trabajar con el sistema de archivos del servidor, con los eventos del núcleo o con módulos propios, eso es on-premise y un desarrollador. Pero si el PHP servía para «pedir, analizar, decidir», el portal en la nube lo cubre con una cadena de dos a cuatro robots que cualquier administrador podrá leer y corregir. Conviene empezar por un inventario: qué pasos de los procedimientos actuales chocan con la falta de código, y montarlos a partir de acciones ya listas, como se describe en la visión general de los procesos de negocio.

Conclusión

«Código PHP» es solo de la versión on-premise; en la nube no se ejecuta código arbitrario. Sustitutos por escenario: petición a una API, «Petición HTTP GET/POST»; análisis de la respuesta, «Extraer valor de un JSON por ruta»; texto, «Extraer mediante expresión regular»; comprobaciones compuestas, «Condición compuesta». Los cuatro están en el catálogo de Roboteka: instalación gratuita desde Bitrix24.Market, funcionan tanto en la nube como en on-premise. Si no encuentras la acción que necesitas, describe la tarea y crearemos el robot gratis.