Scribd
Upload
60 views

Backend Flow Trace

This document outlines the steps to trace a backend flow in a digx application from the REST endpoint to the host system: 1. Find the REST endpoint by checking the network requests from the front-end. 2. Trace from the REST endpoint to the service class. 3. Trace from the service to the domain/entity class. 4. Trace from the entity to the repository class to determine if it calls a local or remote adapter. 5. Trace from the remote adapter to the host adapter, which contains the actual queries to the host system database.

Uploaded by

Austin Smith
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as RTF, PDF, TXT or read online on Scribd
60 views

Backend Flow Trace

This document outlines the steps to trace a backend flow in a digx application from the REST endpoint to the host system: 1. Find the REST endpoint by checking the network requests from the front-end. 2. Trace from the REST endpoint to the service class. 3. Trace from the service to the domain/entity class. 4. Trace from the entity to the repository class to determine if it calls a local or remote adapter. 5. Trace from the remote adapter to the host adapter, which contains the actual queries to the host system database.

Uploaded by

Austin Smith
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as RTF, PDF, TXT or read online on Scribd
You are on page 1/ 16

Backend flow Tracing

Step1: Finding the REST


Submit any transaction from the front end and check the REST which is fired.
To check the rest, open developer option -> Go to Network -> apply filter as a ‘digx’ -> check
the rest
Check the request method and the sub resources to find the rest from editor.
Example:
for given below ss, request method is GET, sub resource is issuedCheques and rest is
demandDeposit rest.
If url is formed with digx/v1 then it is base url. for customized transaction we need to maintain
url as digx/cz/v1

Package structure which contains appx is the REST class


Example: com.ofss.digx.appx.dda.service.cheque
Parameters for rest can be Path parameters, query parameters or in the format of complete dto.
Step2: Finding the service
From rest to find service trace the method which is called from service object.
Package structure which contains app is the service class
Example: com.ofss.digx.app.dda.service.cheque
To check access and security we have checkAccessPolicy. For checkAccessPolicy to be enabed
we need to give entry in below table for the fully qualified service name followed by the method
name
Query:
select * from DIGX_AZ_RESOURCE_ACTION where resource_id like '%
com.ofss.digx.app.dda.service.cheque.ChequeManagement.list%'
select * from DIGX_AZ_ENTITLEMENT where id like '%
com.ofss.digx.app.dda.service.cheque.ChequeManagement.list_Perform%'
select * from DIGX_AZ_ENTGROUP_ENT_MAPPING where entitlement_id like '%
com.ofss.digx.app.dda.service.cheque.ChequeManagement.list_Perform%'
select * from DIGX_AZ_ENTITLEMENT_GROUP
To check validation we have system constraints which are given by base product and are not
editable.
For validations we also have business policy which we can edit to add any validations related to
our service from backend. Entry for business policy is given in the digx_fw_config_all_b table
Example: To check business policy check with below query
Query:
select * from digx_fw_config_all_b where prop_id like
'%com.ofss.digx.app.dda.service.cheque.ChequeManagement.list%'
To convert dto object to domain object we have assembler.
Step 3: Find the domain/entity
From service to find domain trace the method which is called from the domain object
Package structure which contains entity is the entity class
Example: com.ofss.digx.domain.dda.entity.cheque

To check the table on digx side, related to the service check below path:
config folder -> orm -> eclipselink -> cfg/mappings -> fully qualified path of the entity class
followed by method name.
to get the path of config folder
click on weblogic manages server -> go to Configuration -> Server Start menu -> Class Path
Step4: Find the adapter
To find the adapter go to the repository
Package structure which contains repository is the repository class
Example: com.ofss.digx.domain.dda.entity.cheque.repository
To check if local or remote adapter is called, query on digx_fw_config_all_b table with prop_id
as adapter name
Example:
In above ss adapter name is ISSUES_CHEQUE_REPOSITORY_ADAPTER
Query:
select * from digx_fw_config_all_b where prop_id =
'ISSUED_CHEQUE_REPOSITORY_ADAPTER'
Step5: Find the host adapter
From the remote adapter check the which core system service is interacting.
To check this
Query:
select * from digx_fw_config_all_b where PROP_ID =
com.ofss.digx.extxface.dda.adapter.cheque.IChequeManagementAdapter.list;
From above ss, check the Assembler and host request object method. From here we get the
idrequest as shown In below ss
Check this idrequest from msthostinterface table in B1A1 schema and take the interface_impl
value and that is our host adapter
Example:
Query:
select * from msthostinterface where idrequest = 'RRCSI02'
Result: com.ofss.extsystem.business.extsystems.adapters.ChequeStatusAdapter
Host adapter contains the actual queries and operations which are done on b1a1 schema.
To check wsdl call
To check host adapter if it is wsdl, Go to assembler and check the request header. From the
request header query on digx schema with below table.
Query:
select * from digx_fw_config_out_ws_cfg_b where service_id like
'%CreatePMSinglePayOut%'
Copy the url column value from query result and put the obpm host ip and port which is to be
taken from digx_fw_config_var_b table. Form a url and check if formed url is working or not.
Query:
select * from digx_fw_config_var_b where prop_id in ('OBPM_HOST_IP',
'OBPM_HOST_PORT') and determinant_value = 'OBDX_BU'

You might also like