MetaData - Retrieve - Revision history

Philip Lacey at 11:56, 18 February 2018

2018-02-18T11:56:56Z

Philip Lacey at 14:42, 11 March 2016

2016-03-11T14:42:20Z

Philip Lacey at 14:07, 11 March 2016

2016-03-11T14:07:07Z

Philip Lacey at 01:00, 5 November 2015

2015-11-05T01:00:09Z

Philip Lacey at 00:59, 5 November 2015

2015-11-05T00:59:45Z

Philip Lacey at 00:55, 5 November 2015

2015-11-05T00:55:44Z

Philip Lacey: Created page with "= Overview = Retrieving data from various sources is the first step in a MetaData process. There are various options to how data can be brought into bxp. This article dis..."

2015-11-05T00:53:46Z

Created page with "= Overview = Retrieving data from various sources is the first step in a MetaData process. There are various options to how data can be brought into bxp. This article dis..."

New page

= Overview =

Retrieving data from various sources is the first step in a MetaData process. There are various options to how data can be brought into bxp. This article discusses the various options and approaches used.

N.B. Please note that this list is for indication purposes only and other connectors and integrations are continuously developed.

= Push or Pull =

The first decision on the data is whether a primary approach of push or pull is going to be used.

* Push: An external system pushes the data into bxp
* Pull: bxp must to another system and pull out the data

There are different times where these approaches are appropriate the primary considerations are security.

== Pull ==

=== Primary security considerations - Connectivity ===

There are different levels of encryption and security considered when considering the Push or Pull.

If security of the remote client is paramount, all solutions suggested will be Push. This allows the client to dictate the hows and when bxp gets its data.

If security measures are in place, bxp can log in to retrieve data. This is usually through one of three methods.

* SFTP file retrieval
* Email attachment retrieval
* API interaction

Where API interaction is required, the API documentation is supplied by the client and a connector is appropriately built. SOAP, XML, JSON, etc are all supported. For security, current client integration examples are not listed here.

bxp to retain its high availability cannot VPN into client infrastructures. VPN connections and their maintenance across the nTier of our web platform is unsustainable and can be easily replaced with PUSH sFTP solutions. Which All n One can provide support on.

=== Primary security considerations - Content Encryption ===

The next consideration is to what level is the data encrypted. Numerous options exist with the most common being AES256 encryption on zip files being transferred. Solutions also exist for PGP based encryption approaches. A case by case review is adopted to facilitate client capabilities and requirements.

== Push ==

This is more generally used when security and automation capability is not yet at an automated enough level. bxp provides a number of mechanisms for data to be pushed into it.

* bxp API: An API for direct data injection [[Scenario_-_bxp_as_a_secure_Website_Data_Store]]
* sFTP: bxp can provide clients with an on demand sFTP account structure.
* The primary bxp interface: Over HTTPS a user can upload files into a bxp system
* All n One email account: All n One can provide an @allnone.ie email address external to the clients environment which bxp can retrieve emails and attachments from

= Conclusion =

All n One can facilitate a variety of retrieval and encryption approaches. The primary question becomes what is the most economic and practical approach to data transfer. This will depend primarily on the client capability and maturity. All n One's development teams would be delighted to discuss how we can help you securely get your data into bxp. Contact us on support@bxpsoftware.com to see how we can help you get your data into bxp.

[[Category:Module Specific:MetaData]]

← Older revision		Revision as of 11:56, 18 February 2018
Line 1:		Line 1:
	= Overview =		= Overview =
		+
		+	{\| class="wikitable" style="width:100%;"
		+	! style="width:20%;" \| Overview
		+	! style="width:20%;" \| Retrieve
		+	! style="width:20%;" \| Input
		+	! style="width:20%;" \| Process
		+	! style="width:20%;" \| Output
		+	\|-
		+	\| style="text-align:center;" \| [[MetaData_-_Start_Here\|Link]]
		+	\| style="text-align:center;" \| [[MetaData_-_Retrieve\|Link]]
		+	\| style="text-align:center;" \| [[MetaData_Process_Input\|Link]]
		+	\| style="text-align:center;" \| [[MetaData_Process_Rules\|Link]]
		+	\| style="text-align:center;" \| [[MetaData_Process_Output\|Link]]
		+	\|-
		+	\|}

@@ Line 78: / Line 78: @@
-[[File:metadata_retrieve_001.png]]
+[[File:metadata_retrieve_001.png|400px]]
@@ Line 84: / Line 84: @@
-[[File:metadata_retrieve_002.png]]
+[[File:metadata_retrieve_002.png|400px]]
@@ Line 90: / Line 90: @@
-[[File:metadata_retrieve_003.png]]
+[[File:metadata_retrieve_003.png|400px]]

← Older revision		Revision as of 14:07, 11 March 2016
Line 66:		Line 66:

	Once the files are within bxp, again decryption of encrypted content can be performed.		Once the files are within bxp, again decryption of encrypted content can be performed.
		+
		+
		+
		+	= VPN =
		+
		+
		+	A Virtual Private Network, creates a bubble which extends the security of your internal network out and around another machine on another network.
		+
		+
		+	VPNs are a massive security consideration. They also offer allow a number of capabilities not possible with other solutions. Consider two networks.
		+
		+
		+	[[File:metadata_retrieve_001.png]]
		+
		+
		+	The base interactions described above are tried, tested, secured and checked protocols for interaction. So the security tends to interact at the edge points.
		+
		+
		+	[[File:metadata_retrieve_002.png]]
		+
		+
		+	In a VPN scenario, a machine, or even an entire network enters a security bubble
		+
		+
		+	[[File:metadata_retrieve_003.png]]
		+

← Older revision		Revision as of 01:00, 5 November 2015
Line 3:		Line 3:

	Retrieving data from various sources is the first step in a MetaData process. There are various options to how data can be brought into bxp. This article discusses the various options and approaches used.		Retrieving data from various sources is the first step in a MetaData process. There are various options to how data can be brought into bxp. This article discusses the various options and approaches used.
−
−
−	~~N.B. Please note that this list is for indication purposes only and other connectors and integrations are continuously developed.~~

← Older revision		Revision as of 00:55, 5 November 2015
Line 66:		Line 66:
	* The primary bxp interface: Over HTTPS a user can upload files into a bxp system		* The primary bxp interface: Over HTTPS a user can upload files into a bxp system
	* All n One email account: All n One can provide an @allnone.ie email address external to the clients environment which bxp can retrieve emails and attachments from		* All n One email account: All n One can provide an @allnone.ie email address external to the clients environment which bxp can retrieve emails and attachments from
		+
		+
		+	= Audit-ability =
		+
		+
		+	The primary concern for any security department is to be able to audit any process especially in the transfer of data. Numerous auditing reports and details are supported [[Bxp_-_Audit_Logs]]

@@ Line 15: / Line 15: @@
 * Push: An external system pushes the data into bxp
-There are different times where these approaches are appropriate the primary considerations are security.
+There are different times where these approaches are appropriate.  The primary deciding factor is the considerations of associated security.
@@ Line 32: / Line 35: @@
-If security of the remote client is paramount, all solutions suggested will be Push.  This allows the client to dictate the hows and when bxp gets its data.
+If the client is comfortable with their security measures, bxp can log in to retrieve data.  This is usually through one of three methods.
 * SFTP file retrieval
@@ Line 42: / Line 42: @@
-Where API interaction is required, the API documentation is supplied by the client and a connector is appropriately built.  SOAP, XML, JSON, etc are all supported.  For security, current client integration examples are not listed here.
+Where API interaction is required, the API documentation is supplied by the client and a connector is appropriately built.  SOAP, XML, JSON, RESTful, etc are all supported.  For security, current client integration examples are not listed here.
-bxp to retain its high availability cannot VPN into client infrastructures.  VPN connections and their maintenance across the nTier of our web platform is unsustainable and can be easily replaced with PUSH sFTP solutions. Which All n One can provide support on.
+bxp to retain its high availability does not VPN into client infrastructures.  VPN connections and their maintenance across the nTier of our web platform is unsustainable and can be easily replaced with PUSH sFTP solutions. Which All n One can provide support on.
@@ Line 66: / Line 66: @@
 * The primary bxp interface:  Over HTTPS a user can upload files into a bxp system
 * All n One email account:  All n One can provide an @allnone.ie email address external to the clients environment which bxp can retrieve emails and attachments from