Wiki Markup |
---|
{noprint} {float:right\|width=300px\|background=lightgrey\|border=solid blue 2px\|margin=10px\|padding=8px}*Contents* {toc:all=true|depth=4|excerpt=true|indent=14px} {float}\\ {noprint} *Document Logs* *Change log:* || *Date:* || *Author:* || *Version:* || *Changes:* || Completed || Ext. || Int. || Is in Core || | {page-info:created-date\|dateFormat=dd MMMM yyyy}\\ | {page-info:created-user}\\ | 0.1 | Doc. created | No | | | | *Terms and definitions:* || Terms/definitions: || Meaning: || | TBD | To be defined | | N/A | Not applicable | \---- h2. 1 - Purpose of Document This document provides the overall technical details and design of implementing and using the functionality as specified in section 2 - Introduction. This document will not cover implementation details -- for this the code base should be inspected. h2. 2 - Introduction to Functionality Ekspres bank is a company that can help financing a purchase by supplying a 'loan' during the purchase phase. This means that the customer buys a phone during sign up. The customer chooses to buy through Ekspres bank who then pays for the phone. The customer now have a 'loan' at Ekspres bank that the customer will pay back outside our system. The process is done through three steps. # The customer chooses to use ekspres bank, and an container for the purchase is created at EkspresBank thorugh a Soap call (ApplicationCreate) # The customer is the approved or rejected. To get that information Ekspres Bank is polled for a status of the purchase through Soap (ApplicationStatus) # If the customer is approved we then acknowledge the purchase and send a capture message to Ekspres bank through Soap (Capture). It is also possible to cancel the purchase through Soap (cancel) The Soap interaction is implemented and can be found at [https://svn.cdrator.com/svn/dev/integration/Financial/DK/EkspresBank/trunk|https://svn.cdrator.com/svn/dev/integration/logistics/EU/BrightPoint/trunk] Maven dependency {code} <groupId>com.cdrator.integration.financial</groupId> <artifactId>rator-financial-dk-ekspresbank</artifactId> {code} h2. 3 - API There are two ways to use the implementation either through actions or if you are running on an older version of core components h4. Action h6. ApplicationCreateServiceAction h6. ApplicationStatusServiceAction h6. CancelAction h6. CaptureAction h4. Component Brightpoint havnse response = facade.placeOrder(data); h5. Action API The action API is to be used from a workflow. h6. PlaceOrder Action Used for placing an order at Brightpoint@Action @Description("Place a generic order to BrightPoint") public class PlaceOrder { @ActionMethod @ReturnValue(description = @Description("String: DONE, VALIDATION_ERROR, CONNECTION_ERROR")) public String execute(GenericOrder order) throws Exception {} The input is a generic order which must have *GenericOrder:* * It needs a valid Account, used to find brand * A valid deliveryAddress, COMPANY, FIRSTNAME, LASTNAME, STREET, STREETNUMBER, FLOOR, FLOOTUNIT, ZIP, CITY, PHONE * STOCK_CODE in the parameter map on the order to set the deliverycategory * 1-\* order lines. Each of these lines must have a valid productNumber, description, orderlinenumber, TotalExclVat, and a parameter called QUANTITY, if quantity not set a default of 1 will be used h2. h2. 4 - Logging The Logistic implementation will save the XML sent to and from Brightpoint to the table called SOAP_CLIENT_LOG. h2. 6 - Configuration *Needed for polling for status of an order* ENGINE.LOGISTICS.BRIGHT_POINT.USERNAME = username ENGINE.LOGISTICS.BRIGHT_POINT.PASSWORD = password ENGINE.LOGISTICS.BRIGHT_POINT.ORDER_CHECK_URL = order check end point *Needed for placing an order* ENGINE.LOGISTICS.BRIGHT_POINT.USERNAME = username ENGINE.LOGISTICS.BRIGHT_POINT.PASSWORD = password ENGINE.LOGISTICS.BRIGHT_POINT.ORDER_URL = place order end point ENGINE.LOGISTICS.BRIGHT_POINT.MESSAGE_TYPE = message type (example WEBSERVICE) ENGINE.LOGISTICS.BRIGHT_POINT.DECIMAL_DELIMETER = decimal delimeter , or . ENGINE.LOGISTICS.BRIGHT_POINT.CURRENCY_CODE = SEK, DKK, NOK ENGINE.LOGISTICS.BRIGHT_POINT.ALLOW_BACK_ORDER = (FALSE = Hold shipment until complete; TRUE =Send the order when any product is in stock) ENGINE.LOGISTICS.BRIGHT_POINT.SITE =site in the body (example SE100) ENGINE.LOGISTICS.BRIGHT_POINT.ORDER_TYPE =order type, now always set to WWW ENGINE.LOGISTICS.BRIGHT_POINT.COUNTRY_CODE =country code in the header,default is DK ENGINE.LOGISTICS.BRIGHT_POINT.SEND_SMS_NOTIFICATION =Enables/Disables sms notification regarding shop order ENGINE.LOGISTICS.BRIGHT_POINT.INSTANCE = Instance in the header (example SEPROD) h2. 76 - Version || Version \\ || Released || Changes \\ || | *1.0.2* | 15-05-2013 14:51:23 | [ERAICE-667|http://jira.cdrator.com/browse/ERAICE-667] Changed the engine so that it now uses orderline number to match an orderline in the xml to a generic order line | | *1.0.1* | 14-05-2013 10:53:48 | [ERAICE-651|http://jira.cdrator.com/browse/ERAICE-651] Changed the SReceiverDeliveryAddress1, SReceiverDeliveryAddress2 and setSReceiverName logic | | *1.0* | 01-05-2013 15:03:50 | First stable release | \\ |
Page Comparison
General
Content
Integrations