You are on page 1of 16

Account Management API v0.

3
Tabla de contenido
1 User History ..................................................................................................................................... 3
2 Criterios de Aceptación .................................................................................................................. 4
1 USER HISTORY
El objetivo de este microservicio es poder entregar información de un cliente,
usando cualquiera de sus operaciones de búsqueda: por rut, por msisdn o
accountId. La información del cliente debe incluir sus cuentas, los ciclos de
facturación, los métodos de pago.

Se desea actualizar esta funcionalidad agregando dos parámetros en el JSON pre-


calculados, que es igual al response del microservicio en sus tres operaciones,
además se actualiza el sql de referencia para poblar el documento
subscriberResources y el cambio de búsqueda cuando la búsqueda sea por el
parámetro MSISDN.
2 CRITERIOS DE ACEPTACIÓN
1) Se requiere actualizar el documento a almacenar en JSON pre-calculado (punto
4.4. de Account Management API Especificacion v02.4.pdf y US“30923 Account
Manager Refactory”), en el cual se agrega el atributo "subscriber
TypeOffer" dentro del documento “subscribers”.

Documento JSON actualizado

{
"rut": "string",
"account": {
"rut": "string",
"accountId": "string",
"accountIdHigh": "string",
"csLevel": "string",
"custCode": "string",
"accountType": "string",
"accountActivate": "2019-01-31T15:04:17.340Z",
"accountDeactivate": "2019-01-31T15:04:17.340Z",
"externalAccountId": "string",
"state": "string",
"docTypeId": "string",
"docTypeDesc": "string",
"docTypeOutputCode": "string",
"billCycle": {
"accountId": "string",
"billCycle": "string",
"intervalType": "string",
"lastRunDate": "2019-01-31T15:04:17.340Z",
"bchRunDate": "2019-01-31T15:04:17.340Z",
"billCycleDes": "string"
},
"subscribers": {
"rut": "string",
"accountId": "string",
"subscriberId": "string",
"subscriberType": "string",
"subscriberIdContract": "string",
"subscriberActivate": "2019-01-31T15:04:17.340Z",
"subscriberExpired": "2019-01-31T15:04:17.340Z",
"state": "string",
"subscriberResp": "string",
“subscriberTypeOffer”:”string”,
"subscriberResources": {
"subscriberId": "string",
"resourceId": "string",
"resource": "string",
"resourceDescription": "string",
"resourceActivate": "2019-01-31T15:04:17.340Z",
"resourceDeactivate": "2019-01-31T15:04:17.340Z",
"resourceState": "string",
"resourceType": "string"
}
},
"paymentMethod": {
"accountId": "string",
"sequency": "string",
"paymentId": "string",
"paymentCode": "string",
"paymentName": "string",
"paymentFlow": "string",
"pmod": "string",
"entryDate": "2019-01-31T15:04:17.340Z",
"modifyDate": "2019-01-31T15:04:17.340Z",
"userLastModify": "string",
"bankId": "string"
}
}
}

La forma en que se debe poblar este parámetro, se muestra a continuación usando


la query de referencia es el punto 6.3.1 del documento Account Management API
Especificacion v02.4.pdf.

select
a.cscompregno as rut,
b.customer_id as accountId,
b.co_id as subscriberId,
b.type as subscriberType,
b.co_code as subscriberIdContract,
b.CO_SIGNED as subscriberActivate,
b.CO_EXPIR_DATE as subscriberExpired,
b.CH_STATUS as state,
e.ATS_PREPAID_IND as subscriberTypeOffer
from
sysadm.customer_all a,
SYSADM.contract_all b,
SYSADM.CONTRACT_HISTORY c,
SYSADM.RATEPLAN_HIST d,
SYSADM.RATEPLAN e
where
a.cscompregno = '010567335' -- variable
and a.customer_id = b.customer_id
and b.co_id = c.co_id
and c.ch_seqno = (select max(x.ch_seqno)
from
SYSADM.CONTRACT_HISTORY x
where
x.co_id = c.co_id
and x.ch_status = 'a')
and b.co_id = d.co_id
and d.seqno = (select max(y.seqno)
from
SYSADM.RATEPLAN_HIST y
where
y.co_id = d.co_id)
and d.tmcode = e.tmcode;

Como adicional, se agrega el siguiente query sql de referencia, que refleja una
búsqueda por cuenta.

select
a.cscompregno as rut,
b.customer_id as accountId,
b.co_id as subscriberId,
b.type as subscriberType,
b.co_code as subscriberIdContract,
b.CO_SIGNED as subscriberActivate,
b.CO_EXPIR_DATE as subscriberExpired,
b.CH_STATUS as state,
e.ATS_PREPAID_IND as subscriberTypeOffer
from
sysadm.customer_all a,
SYSADM.contract_all b,
SYSADM.CONTRACT_HISTORY c,
SYSADM.RATEPLAN_HIST d,
SYSADM.RATEPLAN e
where
a.customer_id = 602372 -- variable
and a.customer_id = b.customer_id
and b.co_id = c.co_id
and c.ch_seqno = (select max(x.ch_seqno)
from
SYSADM.CONTRACT_HISTORY x
where
x.co_id = c.co_id
and x.ch_status = 'a')
and b.co_id = d.co_id
and d.seqno = (select max(y.seqno)
from
SYSADM.RATEPLAN_HIST y
where
y.co_id = d.co_id)
and d.tmcode = e.tmcode;

Estas tablas SYSADM.RATEPLAN_HIST y SYSADM.RATEPLAN, ya tienen su


tópico en Kafka al igual que sus consumers y sus respectivas replicas en Mongo
DB, instancia producciondb.
2) Se requiere actualizar el documento a almacenar en JSON pre-calculado (punto
4.4. de Account Management API Especificacion v02.4.pdf y US“30923 Account
Manager Refactory”), en el cual se agrega el atributo "subscriberResp" dentro del
documento “subscribers”.

Documento JSON actualizado

{
"rut": "string",
"account": {
"rut": "string",
"accountId": "string",
"accountIdHigh": "string",
"csLevel": "string",
"custCode": "string",
"accountType": "string",
"accountActivate": "2019-01-31T15:04:17.340Z",
"accountDeactivate": "2019-01-31T15:04:17.340Z",
"externalAccountId": "string",
"state": "string",
"docTypeId": "string",
"docTypeDesc": "string",
"docTypeOutputCode": "string",
"billCycle": {
"accountId": "string",
"billCycle": "string",
"intervalType": "string",
"lastRunDate": "2019-01-31T15:04:17.340Z",
"bchRunDate": "2019-01-31T15:04:17.340Z",
"billCycleDes": "string"
},
"subscribers": {
"rut": "string",
"accountId": "string",
"subscriberId": "string",
"subscriberType": "string",
"subscriberIdContract": "string",
"subscriberActivate": "2019-01-31T15:04:17.340Z",
"subscriberExpired": "2019-01-31T15:04:17.340Z",
"state": "string",
"subscriberResp": "string",
“subscriberTypeOffer”:”string”,
"subscriberResources": {
"subscriberId": "string",
"resourceId": "string",
"resource": "string",
"resourceDescription": "string",
"resourceActivate": "2019-01-31T15:04:17.340Z",
"resourceDeactivate": "2019-01-31T15:04:17.340Z",
"resourceState": "string",
"resourceType": "string"
}
},
"paymentMethod": {
"accountId": "string",
"sequency": "string",
"paymentId": "string",
"paymentCode": "string",
"paymentName": "string",
"paymentFlow": "string",
"pmod": "string",
"entryDate": "2019-01-31T15:04:17.340Z",
"modifyDate": "2019-01-31T15:04:17.340Z",
"userLastModify": "string",
"bankId": "string"
}
}
}
Como criterio para completar el nuevo atributo, se debe considerar el
“susbcriberResource” de tipo MSISDN con el atributo “resourceActivate” con
mayor antigüedad, por “subscriber” de cada “account”. El que cumpla esta
condición por cada “account” debe tener el atributo “subscriberResp”=”X”.

Ejemplo:

Para el account 1, existen tres subscriber’s en donde el que tiene mayor antigüedad
es el subscriber 2, ya que tiene fecha de activación el 2019-01-11 y es más antigua
que las fechas del subscriber 1 y 3, por lo tanto el subsciber 2 tendrá el atributo
“subscriberResp”=”X”, y los subscriber 1 y 3 tendrán el atributo
“subscriberResp”=null.
Para el account 2, el cual tiene un único subscriber (el 4) tendrá el atributo
“subscriberResp”=”X”, ya que es el único en la cuenta, mismo caso para el account
3.
Para el account 4, se aplica la misma lógica que para el account 1, siendo el
subscriber 6 con el atributo “subscriberResp”=”X” y subscriber 7 con el atributo
“subscriberResp”=null.
3) En la carga del JSON pre-calculado, se debe actualizar la condición para la
carga del documento “subscriberResources” de tipo MSISDN, se actualiza el
query de referencia de la sección 6.3.4 del documento Account Management API
Especificacion v02.4.pdf.

select
a.co_id as subscriberId,
b.dn_id as resourceId,
c.dn_num as resourceValue,
'Número de celular del subscriptor' as resourceDescription,
b.CS_ACTIV_DATE as resourceActivate,
b.CS_DEACTIV_DATE as resourceDeactivate,
b.CS_STATUS as resourceState,
'MSISDN' as resourceType
from
sysadm.contract_all a,
SYSADM.contr_services_cap b,
sysadm.directory_number c
where
a.co_id = 2523713 --variable
and a.co_id = b.co_id
and b.dn_id = c.dn_id
and b.CS_DEACTIV_DATE is null -- NUEVA CONDICIÓN
and b.sncode = 3 ;
4) En la carga del JSON pre-calculado, se debe actualizar la condición para la
carga del documento “subscriberResources” de tipo IMSI, se actualiza el query
de referencia de la sección 6.3.5 del documento Account Management API
Especificacion v02.4.pdf.

select
a.co_id as subscriberId,
b.dn_id as resourceId,
d.port_num as resourceValue,
'Número de IMSI del subscriptor' as resourceDescription,
b.CS_ACTIV_DATE as resourceActivate,
b.CS_DEACTIV_DATE as resourceDeactivate,D.PORT_STATUS as
resourceState,
'IMSI' as resourceType
from
sysadm.contract_all a,
sysadm.contr_services_cap b,
sysadm.contr_devices c,
sysadm.port d
where
a.co_id = 2523713 -- variable
and b.co_id = a.co_id
and b.co_id = c.co_id
and b.CS_DEACTIV_DATE is null -- NUEVA CONDICIÓN
and c.port_id = d.port_id;
5) En la carga del JSON pre-calculado, se debe actualizar la condición para la
carga del documento “subscriberResources” de tipo ICCID, se actualiza el
query de referencia de la sección 6.3.6 del documento Account Management API
Especificacion v02.4.pdf.

select
a.co_id as subscriberId,
b.dn_id as resourceId,
E.SM_SERIALNUM as resourceValue,
'Número de ICCID del subscriptor' as resourceDescription,
b.CS_ACTIV_DATE as resourceActivate,
b.CS_DEACTIV_DATE as resourceDeactivate,
E.SM_STATUS as resourceState,
'ICCID' as resourceType
from
sysadm.contract_all a,
sysadm.contr_services_cap b,
sysadm.contr_devices c,
sysadm.port d,
sysadm.storage_medium e
where
a.co_id = 2523713 --variable
and b.co_id = a.co_id
and b.co_id = c.co_id
and c.port_id = d.port_id
and b.CS_DEACTIV_DATE is null -- NUEVA CONDICIÓN
AND D.sm_id = E.sm_id;
6) En la carga del JSON pre-calculado, se debe actualizar la condición para la
carga del documento “subscriberResources” de tipo IMEI, se actualiza el query
de referencia de la sección 6.3.7 del documento Account Management API
Especificacion v02.4.pdf.

select
a.co_id as subscriberId,
b.dn_id as resourceId,
d.eq_serial_num as resourceValue,
(e.description||'-'||e.company) as resourceDescription,
b.CS_ACTIV_DATE as resourceActivate,
b.CS_DEACTIV_DATE as resourceDeactivate,
d.eq_status as resourceState,
'IMEI' as resourceType
from
sysadm.contract_all a,
sysadm.contr_services_cap b,
sysadm.contr_devices c,
sysadm.equipment d,
sysadm.equipment_type e
where
a.co_id = 2523713 -- variable
and b.co_id = a.co_id
and b.co_id = c.co_id
and c.eq_id = d.equipment_id
and b.CS_DEACTIV_DATE is null -- NUEVA CONDICIÓN
and d.equipment_type_id = e.equipment_type_id;
7) Cuando se realice la búsqueda sobre los JSON pre-calculados, con la operación
getSubscriberResource, se debe aplicar la siguiente condición:

- Cuando se encuentre el JSON pre-calculado que tenga el MSISDN usado


en la búsqueda, se debe revisar el atributo “subscriberTypeOffer” del
documento “subscriber” asociado al documento “subscriberResources” de
tipo MSISDN que tenga el mismo MSISDN usado como parámetro en la
búsqueda de esta operación, tenga un valor “N” o “M” se debe traer el
documento JSON (pre-calculado) tal como se encuentra.

- En caso de que este tenga un valor “P” (solo contendrá valores “M”, “N” o
“P”), del JSON pre-calculado solo se debe responder, el “subscribers”, con
sus respectivos “subscriberResources” y solo la “account” donde este el
MSISDN.

Ejemplo
Para el ejemplo el “subscriberResource MSISDN (*)” representa al msisdn
ingresado como parámetro y que se encontró en documento JSON pre-
calculado, como se ve en el ejemplo el atributo “subscriberTypeOffer” es igual
a “P”, eso significa que se retorna solo el “subscriber 3” con el “account 2”,
con todos los sub-documentos que estos puedan contener (la burbuja es usada
como referencia).

You might also like