Gestión de Requests 100 Fixed Line Termination en error

Conceptos
Lo primero que hay que entender es qué acciones realiza ese Request.

Se trata de desactivaciones de la parte Fija de una Suscripción. Es como una desactivación “partial” en un Request
18 (que desactiva al móvil), pero en este caso para la parte Fija, que tiene un Request dedicado a esta funcionalidad.

La parte Fija de una suscripción se provisiona sobre MasOSS (“El Bus”), y la forma de relacionarlo con TMS es por el
nº de Pedido, con una “Y” delante (lo que se llama “OT”), que da la información al Bus sobre que esa OT viene de
Yoigo, y por tanto TMS. Toda la gestión a realizar con esta operativa (en general como para todos los requests)
consiste en dejar alineados los estados del Fijo, entre TMS y MasOSS.

Los Requests 100, siempre vienen por un STC, en el que se le cambia de Tarifa Convergente (Fijo + Móvil) a Tarifa
sólo Móvil. Esto significa que en el Request 100, veremos que [F3] nos muestra “SHOWMAIN REQUEST”. Ahí,
veríamos el Request 0 del STC, que además, tendrá en el [F5] el error “Fixed Termination request created,
Subrequest 100 failed”. De las tareas que tiene el Request 0, se ha quedado en la primera, lanzar la baja al Bus.

Por esto (que el Request 100, dependa de un Request 0), lo ideal es ir a ver, en cada caso, todas las acciones que
tiene la suscripción, y así tener una idea clara y cronológica de lo que pretenden hacer sobre ella. Esto es, ir a la
suscripción, y consultar todos sus Requests. Lo mejor es tomar el “Subscription ID”, del Request en error, e ir a
buscar la suscripción por “SUBS ID”.

Otra cosa que hay que aclarar, son las posibles acciones que se pueden realizar sobre el Request 100 en error:

 Reset request (set status to 0) : Rearranca el Request desde el principio, para volver a intentar lo que sea
que quería hacer (en este caso la baja del Fijo). Si hubo un problema puntual de madrugada, al reintentarlo
por la mañana, puede progresar correctamente.

 Bypass network (Set status to 6) : Se asume que la acción ya está realizada en el sistema externo, y se le pide
al Request que termine las acciones posteriores, y así debería finalizar sin error. Esta Opción sólo debe
utilizarse, para este caso, si el fijo está realmente ya dado de baja en MasOSS y Red.

 Handle request (set status to 9) : Con esto, se cancela la acción que iba a realizar el Request, es decir, ya no
vamos a dar de baja el Fijo. Si se utiliza esta opción, hay que handlear también su Main Request, el STC que
lo había lanzado. No hemos encontrado casuísticas que vayáis a gestionar, que impliquen utilizar la opción
de Handle.
Casuísticas
Pasamos a comentar las distintas casuísticas con las que nos podemos encontrar, y el Work-Around a aplicar en cada
una de ellas. Hay una serie de comprobaciones previas, porque no se puede determinar la casuística a partir del
mensaje de error [F5] INFO.

Índice rápido:

 Primeras comprobaciones
 La OT está “Cancelada”
 La OT tiene una _BAJA
 La OT no está de Baja ni Cancelada.
 Errores puntuales, de comunicación o caída de Servidor
 Para todo lo demás…

Primeras comprobaciones
Dado que una posible casuística se relaciona con problemas puntuales de comunicación, o indisponibilidad puntual
de algunos sistemas, lo primero, es Resetear todos los requests que haya en error (como siempre, sabiendo que si
los antiguos los hemos reseteado varios días, sin haberlos gestionado, ya no hace falta seguir reseteándolos).

Una vez hemos reseteado, empezamos a gestionar los que no se hayan solucionado, y tenemos este Request 100 en
error:
┌─────────────────────────────────── CHANGE ───────────────────────────────────┐
│ Request ID: 707759892 (Main request:707435922) MANDATORY│
│ Subscription ID: 21364626 │
│ MSISDN: 640519001 │
│ Customer: 1448668 SALVADOR CANALES BLANCO │
│ │
│ Request Type: 100 Fixed Line Termination │
│ Request Source: 2 Subscription type change │
│ UserId: STC │
│ Create Fees: No │
│ Send SMS: No │
│ SMS Text: │
│ Status: 3 Rejected (error occurred) │
│ │
│ Created: 20210412.00003 (12-04-21 00:00:03) │
│ Activation: 20210412.00003 (12-04-21 00:00:03) │
│ Latest Update: 20210412.50368 (12-04-21 13:59:28) │
│ Handled: 20210412.50368 (12-04-21 13:59:28) │
└──────────────────────────────────────────────────────────────────────────────┘

Vemos el error en el [F5] INFO:

┌───────────────────────────── INFO TEXT ──────────────────────────────┐
│La baja del sevicio fijo ha fallado: OrderID not found, La baja del │
│sevicio fijo ha fallado: OrderID not found │
(ya sabéis, no? sale dos veces, porque ha sido reseteado)

Para obtener más pistas, miramos en [F2] REQUEST PARAM, que para los 100’s, nos debería decir el Pedido, para el
que se está queriendo dar la baja:
┌───────────────────────── REQUEST PARAMETERS ──────────────────────────┐
│Parameter Usage Value Description │
│───────── ──────────────────── ──────────────────── ────────────────────│
│I1 OrderID 0 │

En este caso, el error es lógico OrderID not found, porque no hemos encontrado el OrderID correspondiente a la
suscripción.

Podría dar otra serie de errores diferentes, pero por ahora, nos apuntamos esto.
Como decíamos al principio, ahora lo que tenemos que mirar la secuencia de acciones sobre la suscripción. Para ello,
tomamos el:
Subscription ID: 21364626

Y vamos a ver la suscripción (yo, lo miro en otra ventana, por comodidad al gestionar los errores de la cola, pero
como veáis). Como siempre [F3] [F3] [F3], y [F2] FIND SUBS ID:
┌──────────────────── Yoigo MOBILE SUBSCRIPTION 16-04-21 ────────────────────┐
│SubscriptionID: 21364626 CliType...: CONTFHF020GP │
│MSISDN........: 640519001 / 951416440 BillTarget: 325 CONTRATOFHF0 │
│ICC/SIM.......: 8934044320030677134 PUK1......: 22575059 │
│Subscr.Status.: 8 SUSPENDED OR BARRED PUK2......: 93304675 │
│Barring Mask..: 0000000010000 │
│ PIN1......: 6864 │
│Number Inquiry: NOT SECRET PIN2......: 6251 │
│Agr.Customer..: 1448668 SALVADOR CANALES BLANC │
│PersID/Comp.ID: 24771215P │
│Inv.Customer..: 1448668 SALVADOR CANALES BLANC Provision type: SAPC │
│User .........: 1448668 SALVADOR CANALES BLANC │
│--------------------------------------------------------------------------- │
│CreationDate..: 26-03-2021 PayType.......: PostPaid │
│Activation....: 26-03-2021 Reseller .....: D2 │
│Activated.....: 26.03.2021 14:16:01 Salesman......: D2N01168 │
│ │
└──────────────────────────────────────────────────────────────────────────────┘

Y, ahí, [F3] REQUEST VIEW:

┌───────────────────────── Yoigo Requests 21-05-21 ──────────────────────────┐
│ ID MSISDN Cust.Nbr Changed by Activate Handled Type S Prov│
│───────── ──────────── ───────── ────────────── ──────── ──────── ──── ── ────│
│707759892 640519001 1448668 SALVADOR CANAL 12-04-21 12-04-21 100 3 │
│707435922 640519001 1448668 SALVADOR CANAL 12-04-21 12-04-21 0 3 │
│706071570 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 1 2 SAPC│
│706071532 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 1 2 SAPC│
│706071535 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 35 2 │
│705971723 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 13 2 SAPC│
│706071312 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 102 2 SAPC│
│706071533 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 8 2 │
│706071534 640519001 1448668 SALVADOR CANAL 30-03-21 30-03-21 8 2 SAPC│
│705706791 640519001 1448668 SALVADOR CANAL 26-03-21 26-03-21 14 2 │
│705706802 640519001 1448668 SALVADOR CANAL 26-03-21 26-03-21 8 2 │
│705706803 640519001 1448668 SALVADOR CANAL 26-03-21 26-03-21 8 2 │
└──────────────────────────────────────────────────────────────────────────────┘

He marcado en rojo el Request 100 que encontramos en la cola de errores, y su Main Request 0, con el STC. No
parece tener nada más (anteriormente, sólo vemos el Request 14 de creación de la parte fija, con sus 8’s, y después
el 13, de creación de la parte móvil, con sus otros 8’s, su 102, y sus 35 con sus 1’s).

También podemos mirar desde esa suscripción el Pedido correspondiente, con [F7] MOSUB FUNCTION; F) Order
View
┌─────────────────────────────────── ORDER ────────────────────────────────────┐
│OrderID/status: 26750075 / 12 ONGOING OrderType: 1 │
│ContractID ...: 1E8C03C Custnum .: 1448668 │
│MSISDN .......: 640519001 / 951416440 AuthCType: │
│ICC ..........: 8934044320030677134 AuthCusID: │
│CLIType ......: CONTFHF020GP OrdererIP: 95.169.251.3 │
│Payment Method: PostPaid Campaign : │
│SubscriptionID: 21364626 FATime ..: 0.00 │
│Create request: 705971723 Reseller : D2 │
│MNP ..........: APOR RiskCode: I33;CIC601 │
│Operator .....: Orange Salesman.: D2N01168 │
│Old ICC ......: OrderCh..: fusion_telesales │
│Old P.Method .: PostPaid Source ..: newton │
│Referee ......: O.Payment: │
│Curr LO Status: Paid Created .: 25.03.2021 15:48:21 │
│Delivery Type : 0 Printed .: 25.03.2021 15:56:02 │
│Agr.Customer .: SALVADOR CANALES BLANCO Delivered: 30.03.2021 02:51:47 │
│Inv.Customer .: SALVADOR CANALES BLANCO Closed ..: 00.00.0000 00:00:00 │
└──────────────────────────────────────────────────────────────────────────────┘

Hay que ver que coincida el MSISDN con lo que veíamos en la suscripción:
MSISDN .......: 640519001 / 951416440
En este caso, tenemos suerte. Pero, si aparece sólo el móvil, ese no es el Pedido del Fijo, sino el pedido original,
porque el móvil se creó anteriormente con otro Pedido, y luego se le ha añadido el Fijo. En ese caso, se habrá creado
otro pedido de fusión, y en el listado de requests, habríamos visto más historia, incluyendo un STC anterior al que
nos ocupa, que es dónde se le añadió el fijo.

Esto, es importante porque el Pedido va a determinar la OT, en MasOSS. Si no se ve directamente, habría que
buscar los pedidos del cliente, para ver cuál es.

De lo que habíamos visto en la suscripción, tomamos el CIF/NIF/NIE:

│PersID/Comp.ID: 24771215P

Y, miramos, todos los pedidos de ese NIF: ( [F3] [F3] [F5] ORDERS [F7] ALL ORDERS [F5] FIND CUST ID )
┌────────────────────── Yoigo Customers orders 16-04-21 ───────────────────────┐
│ OrderId Created MSISDN CustId Contract StatusCode │
│──────── ─────────────────── ───────── ────────── ──────── ────────── │
│ 2576163 19.10.2009 12:35:48 24771215P 255834 6 │
│ 2607372 28.10.2009 12:51:38 24771215p 25DAC0 6 │
│ 3365436 15.04.2010 16:53:18 24771215P 320B87 6 │
│ 4264957 27.09.2010 17:20:12 24771215P 408198 6 │
│ 5432759 20.04.2011 11:04:27 24771215P 534879 6 │
│26749936 25.03.2021 15:24:51 24771215P 1E8BF93 7 │
│26749985 25.03.2021 15:35:06 24771215P 1E8BFCF 6 │
│26750075 25.03.2021 15:48:21 24771215P 1E8C03C 12 │
│26768472 29.03.2021 20:07:44 24771215P 1E91862 7 │
└──────────────────────────────────────────────────────────────────────────────┘

Pero bueno, en este caso, ya habíamos visto que es el 26750075.

Luego, con el NIF, consultamos en MasOSS. No es buena idea consultar el nº Fijo, o el Pedido, porque eso nos daría
una visión parcial de lo que le puede estar sucediendo, si ha tenido, p.ej., un cambio de domicilio, que le ha
cambiado el nº, o varios intentos fallidos de activación de ese nº, o si la OT tiene una _BAJA.

La línea que he marcado, es la correspondiente al Pedido que habíamos visto, y también coincide el nº Fijo, esa es la
que se está intentando dar de Baja.

Hasta aquí, es lo básico que hay que mirar, para poder gestionar el error del Request 100. En este caso, vemos que la
OT tiene TypeDesc=”Cancelación FTTH + VOIP”, así que vamos a la casuística > La OT está “Cancelada”.
La OT está “Cancelada”
Tras las Primeras comprobaciones, y sabiendo ya el Pedido, el NIF, el nº de Fijo, hemos visto lo siguiente en MasOSS:

Eso significa que no llegó a activarse el Fijo en MasOSS.

Así que, si lo que pretendía el Request 100 era desactivarlo, nos basta con darlo por realizado, es decir: Bypass al
Request 100.

Como lo habremos mirado desde los Requests de la suscripción, veremos que una vez el Request 100 pasa a estado
6, avanza hasta el estado 2 Done, y a continuación su Main Request 0 con el STC, se pondría en marcha
automáticamente, y finalizaría Ok, también.

Posibles mensajes de error:

 La baja del sevicio fijo ha fallado: OrderID not found
 La baja del sevicio fijo ha fallado: Error interno
 La baja del sevicio fijo ha fallado: No se pudo validar el formato JSON de la orden :
Yxxxxxxxx_BAJA
 La baja del sevicio fijo ha fallado: La orden especificada ya ha sido dada de baja
Para determinar la casuística:
 Estado de la OT en MasOSS “Cancelación”.
Workaround:
 Bypass

La OT tiene una _BAJA

Si, después de las Primeras comprobaciones, vemos algo como esto en MasOSS (recordad, buscando por
NIF/NIE/CIF, que si no, no se vería todo):

Lo que vemos es que las dos primeras OTs, son un cambio de domicilio, la última es el resultado (habiendo cambiado
tecnología y numeración), y la de encima, es su OT de _BAJA.

Esto, significa que la Baja, ya ha sido realizada, y por eso el Request falla. Así que, sólo queda hacer que el Request
100 avance, y termine la baja del fijo sobre TMS, quedando así todo alineado. Esto significa que hay que hacer
Bypass al Request 100.
 Posibles mensajes de error:
 La baja del sevicio fijo ha fallado: OrderID not found
 La baja del sevicio fijo ha fallado: Error interno
 La baja del sevicio fijo ha fallado: No se pudo validar el formato JSON de la orden :
Yxxxxxxxx_BAJA
 La baja del sevicio fijo ha fallado: La orden especificada ya ha sido dada de baja
Para determinar la casuística:
 Estado de la OT en MasOSS _BAJA
Workaround:
 Bypass

La OT no está de Baja ni Cancelada.

En estos casos, después de haber hecho las Primeras comprobaciones, constatamos que la OT en MasOSS (SIEMPRE,
buscando por NIF/NIE/CIF) aparece activa (WorkOrderName=”ALTA” / ”CD_A” / (…), y StatusDesc=”OT_CERRADA”):

Y en estos casos, también aparecería activo en Red Fija:

Si el mensaje de error, no es uno de los del apartado Errores puntuales, de comunicación o caída de Servidor, y ya
hemos reseteado el Request, el problema debe estar en los datos de la OT en MasOSS (El Bus).

Habría que escalarlo a Provisión, o tener algún modo de realizar esa baja sobre el Bus, y que se traslade a Red.

Una vez la baja ya se hubiera realizado, veríamos su OT de _BAJA, junto a la que habíamos visto activa:
Y, en red, también se verá:

(a veces tarda unas horas, a veces es instantáneo)

Y, para acabar, como se hace con todos los demás Request que se escalan, el último paso sería hacer Bypass al
Request 100. Su STC “Main Request”, debería avanzar solo, a continuación.

Posibles mensajes de error:

 La baja del sevicio fijo ha fallado: OrderID not found
 La baja del sevicio fijo ha fallado: Error interno
 La baja del sevicio fijo ha fallado: No se pudo validar el formato JSON de la orden :
Yxxxxxxxx_BAJA
Para determinar la casuística:
 Estado de la OT en MasOSS _BAJA
Workaround:
 Escalar; Comprobar _BAJA; Bypass

Errores puntuales, de comunicación o caída de Servidor

Hay ciertos errores, que simplemente han sido provocados por un problema puntual de comunicaciones, o de
indisponibilidad de algún Servidor, de los muchos implicados.

En general, si vemos la palabra GATEWAY, o TIME-OUT, o una URL con una dirección IP, tanto para estos Request
100, como para otros (incluyendo respuesta de SAP commands), se trata de este tipo de errores.

Algunos ejemplos:

LA BAJA DEL SEVICIO FIJO HA FALLADO: STATUS CODE 408

FOR READ OPERATION AT URI
HTTP://95.169.251.117:96/API/ORDERS/1/ORDER/Y20463707/
TERMINATELANDLINE 408 READ
HTTP://95.169.251.117:96/API/ORDERS/1/ORDER/Y20463707/
TERMINATELANDLINE

LA BAJA DEL SEVICIO FIJO HA FALLADO: <HTML>

<HEAD><TITLE>502 BAD GATEWAY</TITLE></HEAD> <BODY
BGCOLOR=""WHITE""> <CENTER><H1>502 BAD
GATEWAY</H1></CENTER>
<HR><CENTER>NGINX/1.11.10</CENTER> </BODY> </HTML>

LA BAJA DEL SEVICIO FIJO HA FALLADO: <HTML>

<HEAD><TITLE>504 GATEWAY TIME-OUT</TITLE></HEAD> <BODY
BGCOLOR=""WHITE""> <CENTER><H1>504 GATEWAY
TIME-OUT</H1></CENTER>
<HR><CENTER>NGINX/1.11.10</CENTER> </BODY> </HTML>

LA BAJA DEL SEVICIO FIJO HA FALLADO: UNHANDLED

DATABASE ERROR

LA BAJA DEL SEVICIO FIJO HA FALLADO: CONNECTION

FAILURE FOR HOST 95.169.251.117 PORT 96 TRANSPORT TCP.
(9407)
En estos casos, la única solución es reintentar, para ver si se ha restablecido la comunicación, o lo que estuviera
provocando el problema puntual. Esto es, Resetear el request.

Debería avanzar (o caer en otro error, claro), pero si se repite el error, en un número razonable de reseteos o de
tiempo, escaládnoslo.

Posibles mensajes de error:

 (…) BAD GATEWAY (…)
 (…) GATEWAY TIME-OUT (…)
 (…) FOR READ OPERATION AT URI HTTP://95.169.251.117:96/API/ORDERS/1/ORDER/ (…)
Para determinar la casuística:
 Memo Text del Request ( [F5] )
Workaround:
 Reset Request

Para todo lo demás…

… escaladlo.

Estos errores han sido el 99,999% de los que hemos ido encontrando. No obstante, ya supongo que saldrán cosas
nuevas, y en ese caso, tendréis que escalárnoslos, para que encontremos la causa, y os preparemos un Work-
Around, para añadir a esta operativa, o que no pueda hacerse nada más que escalarlo a Qvantel, o a Provisión.