Page Comparison

{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 Brightpointbank is a logisticcompany providerthat whocan serviceshelp multiplefinancing countriesa purchase Theby implementationsupplying cana be'loan' foundduring atthe 
[https://svn.cdrator.com/svn/dev/integration/logistics/EU/BrightPoint/trunk|https://svn.cdrator.com/svn/dev/integration/logistics/EU/BrightPoint/trunk]

Maven dependency

<groupId>com.cdrator.integration.logistics</groupId>

<artifactId>rator-logistics-eu-brightpoint</artifactId>

It is SOAP based, and works through placing an order and then polling for the status of the order.

h2. 3 - API

There are two ways to use the implementation either through a direct java call, or through an action in a workflow

h5. Java API

Brightpoint have a Java API located in the class com.CDRator.billing.logistics.brightpoint.BrightPointFacade.java

There are three public methods./**
 * PlaceOrder on the BrightPoint gateway
 *
 * @param data All the information needed to place an order
 * @return
 * @throws SysException
 */
public OrderV20Response placeOrder(PlaceOrderData data) throws SysException {}

/**
 * Get Orders based upon the order number, as generated in CDRator system.
 *
 * @param treeData information needed to make the request
 * @param purchaseNumber The order numbers for fetch orders for.
 * @return
 * @throws SysException
 */
public ArrayOfOrderhead getOrderHistoryByPurchaseNumber(ParameterTreeData treeData, List<String> purchaseNumber)
            throws SysException {}

/**
 * Get Orders from a given date till now.
 *
 * @param treeData information needed to make the request
 * @param date
 * @return
 * @throws SysException
 */
public ArrayOfOrderheadV2 getOrderHistoryByDate(ParameterTreeData treeData, Date date) throws SysException {}
ExampleBrightPointFacade facade = new BrightPointFacade();
OrderV20Responsepurchase 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.
4 - Engine

The Brightpoint project contains an engine used for polling Brightpoint for status on an order called BrightPointPollOrderEngine

The package is located at *com.CDRator.billing.logistics.brightpoint.engine.BrightPointPollOrderEngine* and it extends engine branded and uses the ENGINE_PARAMETER_PATH='ENGINE.LOGISTICS.BRIGHT_POINT'.

The engine for loop over at GenericOrders in status Processing.
# It will then poll Brightpoint for status on the orders.
# it will update the GenericOrder responseParameters with a BRIGHTPOINT_STATUS=xxxxxxx
# if the response for an order contains tracking_ids those will be  added to the GenericOrder responseParameters in a semicolon list  TRACKING_ID=xx:yy:zz
# If an GenericOrderLine have been delivered the GenericOrderLine responseParameters will also have DELIVERED=TRUE
# If the response for a line contains additional information(ESN,  ICC...) that information will be added to the GenericOrderLine  responseParameters in a semicolon seperated list SERIAL=xx:yy:zz
# If 1-\* lines on a genericOrder have been delivered the engine will  invoke the hookpoint specified on the GenericOrder. It is then up to the  workflow to determine if the action should be taken on partially  delivered order, or we should just keep polling.
# If an order is fully delivered in on go, the hookpoint on the GenericOrder will still be invoked.

h5. Engine Specific Properties

Some properties in the configuration file are specifically for engines, and are shown in the format below:
|| wrapper.java.mainclass || com.CDRator.billing.engine.GenericEngineStarter ||
| | This property specifies the java path for   CDRator engine starter.  Mainclass property must be specified in order   to start the engine  framework. |
| | |
|| wrapper.app.parameter.1 || \-S ||
| | The \-S property is optional. But it is a   parameter for the GenericEngineStarter which enables the engine starter   to make a sleep just before it stops. The reason for this is that in   cases where the engine has nothing to do, it can complete very quickly.   The Windows NT Service environment might see this as a possible failure   and will do a failure count. When the count reaches a specific number,   it will halt completely and has to be restarted manually. |
| | |
|| wrapper.app.parameter.2 || 10 ||
| | Number of seconds engine starter must sleep before it stops. |
| | |
|| wrapper.app.parameter.3 || \-P ||
| | Specifies that the next parameter is to start the engine. |
| | |
|| wrapper.app.parameter.4 || com.CDRator.billing.logistics.brightpoint.engine.BrightPointPollOrderEngine ||
| | Specifies the java path of the engine that the generic engine starter  must start. |
| | |
|| wrapper.app.parameter.5 \\ || Name of the engine \\ ||
| | Name of the engine \\ |
|| wrapper.app.parameter.6 \\ || Number of instances \\ ||
| | Number of instances \\ |
|| wrapper.app.parameter.7 \\ || PartnerCode \\ ||
| | This is a reference to PARTNER_CODE on GenericOrder table. This basically chooses which generic orders to pick up \\ |
As for the actions all the parameters in the configuration section needs to be setup

h2. 5
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. 7 - 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 |
\\