Log
From UG
(→Parent Mantis) |
|||
(22 intermediate revisions not shown) | |||
Line 3: | Line 3: | ||
==Info== | ==Info== | ||
===Parent Mantis=== | ===Parent Mantis=== | ||
- | * mantis: [http://ct.jaguarfreight.com/mantis/view.php?id=2570 0002570 | + | |
+ | * mantis: [http://ct.jaguarfreight.com/mantis/view.php?id=2570 0002570] | ||
+ | |||
===Scope of this wiki=== | ===Scope of this wiki=== | ||
This wiki covers the logging of CT2 user's activities which make the changes to system,'' including system's actions''. | This wiki covers the logging of CT2 user's activities which make the changes to system,'' including system's actions''. | ||
Line 106: | Line 108: | ||
'''0003479''': Create a better framework for logging Air Status EDI Messages | '''0003479''': Create a better framework for logging Air Status EDI Messages | ||
- | * Provide control the unbroken handling of received Freight Status | + | === Timely processing=== |
- | :* | + | * Provide control the unbroken handling of received Freight Status Answer[http://www.iata.org/whatwedo/cargo/efreight/pages/glossary.aspx] (FSA) messages on airdescartes FTP. |
+ | :* Accordingly to set "Air Status/EUAN updates frequency in seconds(s)" in Air Status/EUAN Admin section of CT2. | ||
+ | NOTE: This related also to mantis '''[http://ct.jaguarfreight.com/mantis/view.php?id=3523 3523]''' ''Rearchitect the interface: connect probl btw CT2 & FTP Server for TMS, Air Status & EUAN BP.'' | ||
+ | |||
+ | === Complete handling === | ||
+ | * Handle the received files | ||
+ | :* Valid files ''(update CT)''. Keep them on FTP after use in "Valid files" directory. | ||
+ | :* Not valid files ''(don't update CT)''. Keep them on FTP in proper directories - "Not valid files", "Files with dates in future". | ||
+ | :* We should keep messages for 1 year. Every 3 months compress all messages into a zip file and store them that way on ftp. | ||
+ | * Record derived information of each Message | ||
+ | :* If "<Status>" tag presented in Message use status details from [http://ct.jaguarfreight.com/wiki/Air_Status_EDI#Expanded_Consignment_Status_description Expanded Consignment Status description] | ||
+ | :* If "<Status>" tag missed in Message use details from "<OtherServiceInformation>" tag | ||
+ | ::* "NO RECORD FOUND" should be ignored when MAWB is out of system. | ||
+ | NOTE about Error.txt: | ||
+ | * Log meaningful information (when available); | ||
+ | * Line delimiter could be added. | ||
+ | |||
+ | === Increase performance === | ||
+ | ''Taken from mantis, written in note (0012035) by Vlad:'' | ||
+ | :* 1) log error message instead of throwing an exception when incomingStatuses is null. | ||
+ | :* 2) remove unnecessary processing: | ||
+ | ::* Example: ''xmlEnvelope and messageTypeUnmarshaller (line 149) seems to be redundant as identical messageType can be found in IncomingAirEnvelope (line 153).<br>This can save (1) second ftp file download, (2) second XML file parsing.'' | ||
+ | :* 3) use FTP RENAME command instead deleting and re-uploading files; | ||
+ | :* 4) attempt to create directories should be done at most once, immediately after internal application is deployed. | ||
+ | |||
+ | === Extended description in System Log === | ||
+ | :* Display full description of received status | ||
+ | ::* also display every status record in Update Log of related CT; | ||
+ | ::* would be good to keep the last received status directly in shipment to be able to display it without request to CT Update Log. | ||
+ | :* Display additional information (not only Dates but Airports/Carriers or smth). | ||
+ | |||
+ | === Post-Implementation Notes === | ||
+ | * Features which were not implemented: | ||
+ | ** Handling of ''"Files with dates in future"'' isn't defined for AIR statuses but only for TMS. No need to implement. | ||
+ | ** Archiving/compressing ''(every 3 moths)'' of received messages. <span style="color:red">Separate task should be created.</span> | ||
+ | ** Status label in shipment. <span style="color:red">Separate task should be created.</span> | ||
+ | * "<Status>" and "<OtherServiceInformation>" tags are handled separately. | ||
+ | * ''"NO RECORD FOUND" should be ignored'' means '''not logged'''. | ||
+ | |||
+ | == SOW 3 Improve user interface == | ||
+ | |||
+ | mantis: | ||
+ | |||
+ | spec: below | ||
+ | |||
+ | === SOW 3 Requirements === | ||
+ | |||
+ | Per Marc: | ||
+ | |||
+ | * it is inconvenient that user needs to expand tree to see results. So by default it should be expanded | ||
+ | * to go futher we should possibly switch to table like front end (vs tree). This type of approach we had in [[Log v1]] and CT1 | ||
- | + | Per Alex/Roma: | |
- | + | ||
- | + | ||
- | * | + | * Log missing filters section when called from CT Editor. Inconvenient for QA and Support and possibly end users |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | === SOW 3 Solution === | |
- | + | TBD | |
- | == | + | == SOW 4 Add logging of purchase invoices == |
- | + | ||
- | + | mantis: | |
- | + | spec: below | |
- | + | * log all events related to PIs: created, updated, deleted | |
+ | * log under Acc section |
Current revision as of 00:11, 3 August 2013
Contents |
[edit] Info
[edit] Parent Mantis
- mantis: 0002570
[edit] Scope of this wiki
This wiki covers the logging of CT2 user's activities which make the changes to system, including system's actions.
[edit] Glossary
[edit] Core Business Need
This is a report on all user activity in the system.
[edit] Business Requirements
You can search by date or/and component and see who and when set or changed any value in the system.
- 1) System Logs
- 2) Admin Logs
- 3) Acc Logs
- 4) Operation Logs
- 5) Shipment Logs
- 6) Master Logs
[edit] SOW 0
Mantis: 2397 (* Ops Admin Misc) Create log for Admin
Core requirements:
This feature displayed in the table form which contains the next details of Admin changes:
- 1) When change happened,
- 2) Who is made changes,
- 3) What was changed,
- 4) Admin Component (and Sub-Component) where change happened.
Admin Update Log should reflect all changes in Admin part of CT2.
Admin Update log should provide a search feature. All columns of Admin Update log should have an able to a sorting.
[edit] Solution
[edit] Components (and Sub-Components)
- Address Book: Company-City List, Transportation, Vendors, Bill To Parties
- Client Companies: Client Companies, Client Companies Groups, Credit Limits, Credit Terms, Credit Statuses
- Create CT Admin: Numbers, CT1 vs CT2 Client Companies
- Users and Offices: Offices, Jaguar Users Groups, Jaguar Users, Non-Jaguar Users
- Geography: Regions, Countries, Airports, Port/Terminals, Busiest Port/Terminals
- Transportation: Shipping Terms, Default Authorization Methods, Move Types/HBLs, Container Sizes, Container Types, Customs Statuses, FDA Statuses, Packaging Pallet Types, Delivery Date Types, PO Issued By
- Carriers: Airlines, Steamshiplines
- Automated Estimated Delivery Dates: Air, FCL AW, FCL MLB, LCL AW, LCL MLB
- Users Access Admin: Basic Ops, Super Ops, Basic Acc, Super Acc, Management, Sales etc
- Client App Admin: Manage RSS News Feeds, Testimonials, Mobile Providers, BCC List, TMS
- Shipment Invoices Recovery: Number of Invoice what was changed
[edit] Columns
- Date: Date when change happened. Displayed in standard CT2 date format.
- Jaguar User / Office: Name of Jaguar User who made changes (and User's Office).
- Event: Type of happened change: { Add, Remove, Edit, Archive, Restore }.
- Component: Name of the component where change happened.
- Sub-Component: Name of the sub-component where change happened.
- Field: Name of the field what was changed.
- Change: Old and new values of changed fields in format old value => new value.
Example:
[edit] SOW 1
Mantis: 3094 (Main Log) Changes: 1) additional filters 2) downloads to xls
Core requirements:
r1) add ability to download "log results" into excel
r2) add filters ( Multiselect):
- Operator Name
- Office
- Internal Group
- Client
[edit] Solution
Connection logic for filters (Operator, Client user, Office, User group):
- Within multiselect filters use OR connection.
- Connect above-mentioned filters each other by OR also.
- Connect them to other filters by AND operator.
NOTE: "Show system logs" checkbox was added. This control object doesn't affect of an any result of query. It only controls the showing/hiding of system messages (have empty User/Office column) in report.
Example of report downloaded into Excel:
[edit] SOW 2 Create a better framework for logging Air Status EDI Messages
0003479: Create a better framework for logging Air Status EDI Messages
[edit] Timely processing
- Provide control the unbroken handling of received Freight Status Answer[1] (FSA) messages on airdescartes FTP.
- Accordingly to set "Air Status/EUAN updates frequency in seconds(s)" in Air Status/EUAN Admin section of CT2.
NOTE: This related also to mantis 3523 Rearchitect the interface: connect probl btw CT2 & FTP Server for TMS, Air Status & EUAN BP.
[edit] Complete handling
- Handle the received files
- Valid files (update CT). Keep them on FTP after use in "Valid files" directory.
- Not valid files (don't update CT). Keep them on FTP in proper directories - "Not valid files", "Files with dates in future".
- We should keep messages for 1 year. Every 3 months compress all messages into a zip file and store them that way on ftp.
- Record derived information of each Message
- If "<Status>" tag presented in Message use status details from Expanded Consignment Status description
- If "<Status>" tag missed in Message use details from "<OtherServiceInformation>" tag
- "NO RECORD FOUND" should be ignored when MAWB is out of system.
NOTE about Error.txt:
- Log meaningful information (when available);
- Line delimiter could be added.
[edit] Increase performance
Taken from mantis, written in note (0012035) by Vlad:
- 1) log error message instead of throwing an exception when incomingStatuses is null.
- 2) remove unnecessary processing:
- Example: xmlEnvelope and messageTypeUnmarshaller (line 149) seems to be redundant as identical messageType can be found in IncomingAirEnvelope (line 153).
This can save (1) second ftp file download, (2) second XML file parsing.
- Example: xmlEnvelope and messageTypeUnmarshaller (line 149) seems to be redundant as identical messageType can be found in IncomingAirEnvelope (line 153).
- 3) use FTP RENAME command instead deleting and re-uploading files;
- 4) attempt to create directories should be done at most once, immediately after internal application is deployed.
[edit] Extended description in System Log
- Display full description of received status
- also display every status record in Update Log of related CT;
- would be good to keep the last received status directly in shipment to be able to display it without request to CT Update Log.
- Display additional information (not only Dates but Airports/Carriers or smth).
[edit] Post-Implementation Notes
- Features which were not implemented:
- Handling of "Files with dates in future" isn't defined for AIR statuses but only for TMS. No need to implement.
- Archiving/compressing (every 3 moths) of received messages. Separate task should be created.
- Status label in shipment. Separate task should be created.
- "<Status>" and "<OtherServiceInformation>" tags are handled separately.
- "NO RECORD FOUND" should be ignored means not logged.
[edit] SOW 3 Improve user interface
mantis:
spec: below
[edit] SOW 3 Requirements
Per Marc:
- it is inconvenient that user needs to expand tree to see results. So by default it should be expanded
- to go futher we should possibly switch to table like front end (vs tree). This type of approach we had in Log v1 and CT1
Per Alex/Roma:
- Log missing filters section when called from CT Editor. Inconvenient for QA and Support and possibly end users
[edit] SOW 3 Solution
TBD
[edit] SOW 4 Add logging of purchase invoices
mantis:
spec: below
- log all events related to PIs: created, updated, deleted
- log under Acc section