ZYMAIL OVERVIEW

Introduction:
• ZMail is an offline solution for the projects to obtain CM plans for all network
elements on Mail.
• User sends the XLS file attached in a mail, with all the relevant information in the
standard format, for the Offline Zyday to generate the CM plans to be sent back on
Mail to the user.
• Responsibility of creation, validation and provisioning of network elements lies with
users, since with the Offline solution, there is no backreference of the Netact.

ZMail.xlsx Zmail_defaults.xlsx

ZMail
Server

User PC

CM Plans are sent back to user through

Input Files: mail

ZMail.xlsx: Request configuration Input File. This file is filled by customer and is sent
through the mail to ZMail server

 Will have the sheets HW, Configuration, complex lists, User templates …
Zmail_defaults.xlsx: Default configuration input File. This is Default configuration excel
file which resides in ZMail server
• Some information are defaults for generating the CM plans. For example,
information like System Module Tab in “Default” configuration input file.
• If user provides this info as part of “Request” file then the user provided
information is used else information present in the “Defaults” file is used.
 • Not everything can be in Default xlsx file. As specific attributes such as cells,
antenna must be provided using “Request” input file

Pre-Requirements:
Configuration file:
Conf.py file contains the relevant global parameters and netAct information (i.e., IP,
user login details and Data base details).

Meta Data:
The pre-requirement for execution is to have meta data upgraded with each netAct
release. The meta data information will be stored under the below path
“\lib\rac\netact172_sp1711_143\cm\adaptations”
TRPython:
TRPython folder where all the python library files are placed to execute zymail.

Audit launcher:
audit_launcher script is used to set the python environment

How To execute Zymail Code Base:

From the command line use the below command
./audit_launcher.sh lib/zyrunner.py

High level Over view

Request Release HW
ID Techno Name Conf
1 2G S16_3+GF16 FX_2G

For each request id, depending on the available release and technology and adaptation
information either 1 or 2 CM plan files will be generated.

Here there will be 2 CM Plan files generated one for BSC and one for BTS because there are
2 adaptations available with the Techo:2G and Release: S16_3+GF16 respectively as shown
below

Techno mo
name Release name adaptation SW release level root class
2G S16_3+GF16 NOKBSC S16_3 BSC BCF
2G S16_3+GF16 NOKBTSFM GF16 BTS MRBTS
Code Flow:
Step1: Zyrunner constructor, load the zmail.xlsx internally into requested_configuration
Step2: getdefault_configuration:
This method will check the list of zmail_default.xlsx files in input folder. If the list is empty
then process will end and if the list is not empty then it sorts this list according to their
timestamp and stores the first file internally into default_configuration

Step3: get_adaptation_definition:
get_adaptation_definition() method will take the zmail_default.xlsx and zmaill.xlsx as inputs
and read the adaptation_definition sheet if exists and stores this information in a nested
dictionary format with key as a combination of ['Techno name','Release name',
'adaptation']

output format:
'2G': {'S16_3+GF16':
{'NOKBTSFM': {'techno_name': '2G', 'rt_class': ['MRBTS'], 'sw': 'GF16', 'mo_level': 'BTS'},
'NOKBSC': {'techno_name': '2G', 'rt_class': [u'BCF'], 'sw': 'S16_3', 'mo_level': 'BSC'}},
'S16_3+EX16':
{'NOKBTSFM': {'techno_name': '2G', 'rt_class': ['MRBTS'], 'sw': u'EX16', 'mo_level': 'BTS'},
'NOKBSC': {'techno_name': '2G', 'rt_class': ['BCF'], 'sw': 'S16_3', 'mo_level': u'BSC'}}}

Here techno name: 2G, Release name is S16_3+GF16, S16_3+EX16 with adaptions are
NOKBTSFM, NOKBSC.
Step 4: get_hw_info(): This method reads the sheet HW from requested_configuration
(zmail.xlsx) and checks the HW reference from sheets SYSTEM_MODULE, TRANSPORT_UNIT,
RADIO_MODULE and BASEBAND_MODULE of default_confiiguration(zmail_default.xlsx) and
forms a HW dictionary with key as ‘Conf alias’ along with the sub dictionaries of SMOD,
RMOD, LCELL, TRS and wiring dictionaries with the key as ‘module name’.

Output format:
HW_output.txt
Step 4: get_complex_list_tab: This method will store the complex_lists sheet internally in a
nested dictionary grouped by item_number

Output format:
{u'PLMN-PLMN/BSC-937651/BCF-345': {u'complex_long_list': [{u'a': u'1', u'c': u'3', u'b': u'2',
u'd': u'4'}, {u'a': u'11', u'c': u'13', u'b': u'12', u'd': u'14'}, {u'a': u'21', u'c': u'23', u'b': u'22',
u'd': u'24'}, {u'a': u'31', u'c': u'33', u'b': u'32', u'd': u'34'}]}}

Step 4: get_matrix: This method will read the matrix and parameters sheets from
default_conf and stores in a result nested dictionary based on the keys ‘SW’, ‘adaptation’
and ‘class’
Output format:
u'NOKLTE': {u'FL16A': {u'SMOD': [{u'MO Level': u'BTS', 'parameters': {u'prodCodePlanned':
u'loop:prodCode', u'prodCode': u'loop:prodCode'}, u'Existance Condition': u'', u'SW': u'FL16A', u'MO
Id': u'loop:id', 'transcodings': {u'prodCodePlanned': None, u'prodCode': None}, u'Adaptation':
u'NOKLTE', u'Class': u'SMOD', u'Loop': u'get_next_smod'}],

Step 5: get_requests: This method will read the configurations sheet from the requested
config xlsx and stores all the requests in a dictionary
Output format:
{u'1': {u'Request ID': u'1', u'Release Name': u'S16_3+GF16', u'Techno': u'2G', u'HW Conf': u'FX_2G',
'_line_': 1},
u'3': {u'Request ID': u'3', u'Release Name': u'FL16A', u'Techno': u'4G', u'HW Conf': u'FX_4G', '_line_':
3},
u'2': {u'Request ID': u'2', u'Release Name': u'RNC16+WBTS16', u'Techno': u'3G', u'HW Conf':
u'FX_3G', '_line_':
2}}
step 6: get_all_sheets: This method will read all the remaining sheets(other than sheets to
ignore lost) in requested config xlsx file store that information in internally
output format:
{'NOKBSC-BTS':
[{u'$instance': 100, u'$sector': 0, u'$parentDN': u'PLMN-PLMN/BSC-937651/BCF-345',
u'$template': u'TUTU_micro', u'$band': 900, u'LAC': 89},
{u'$instance': 101, u'$sector': 1, u'$parentDN': u'PLMN-PLMN/BSC-937651/BCF-345',
u'$template': u'TUTU_micro', u'$band': 900, u'LAC': 89},
{u'$instance': 102, u'$sector': 2, u'$parentDN': u'PLMN-PLMN/BSC-937651/BCF-345',
u'$template': u'TUTU_micro', u'$band': 900, u'LAC': 89}],

'NOKBSC-BCF': [{u'Q': u'b', u'list.1.toto': 1, u'complex_long_list': u'#Complex_Lists#', u'$parentDN':

u'PLMN-PLMN/BSC-937651', u'$template': u'BCF_DEFAULT_Exemple', u'list.1.tata': 2, u'list.2.tata': 4,
u'Request ID': 1, u'P': u'a', u'R': u'c', u'list.2.toto': 3, u'$instance': 345, u'list_simple.2': u'b',
u'list_simple.1': u'a'}]

Step7: process_requests:

For all requests stored in step 5 this method will

 Get the HW information which was built in step 3 depending on the HW_Conf,
release and technology
  Get all possible adaptations which is built in step 2 for the technology and release
using Adaptation and class information check for the corresponding sheet info which
was built in step 6 For example if adaptation is NOKBTSFM and class is MRBTS then it
will check for the information which was built in step 6 with key
“NOKBTSFM_MRBTS”.
 Depending on the adaptation, class, SW and template, it will build parent MOs and
also build MO information from parent dn and child mo information with reference
to the meta data, which is stored in objects
 By using mo objects information built above, plan.py will parse these mo objects and
write into an XML file.

Example output files:

ZyMail_Req_1_BSC_ ZyMail_Req_1_BTS_
2018-02-20.221128.xml 2018-02-20.221128.xml