I have a list of users maintained by an external source and need to synchronize local users in Business Objects with this list (or at least add any new users) on a daily basis.
The only way I can find to do this in BO is to create a csv-file and import it manually through the interface. Is there a way to automate this with a script?
We have Business Objects 4.2 SP3
Yes, you can certainly create a program to synchronize users. See the BusinessObjects Java Developers Guide for information on creating users.
Related
I have 2 systems let's call them i and j. Each have it's own database.
Each have a registration page, where a user is inserted in a user table.
What is the best way to synchronize both tables, where if any user registers at system i it will be also registered at system j.
Notes:
I cannot read from each other databases directly.
I can do small changes in the code if needed and it will not affect the system performance or natural behavior.
I can create API's for both systems if needed.
I can add any tables or fields if needed.
I can create any cron jobs unless it will affect the performance of the system or server.
I'm using cPanel.
Technologies:
MySQL
PHP
REST API's
The fact that you list cpanel as a technology shows you're working with an inflexible budget hosting vendor. So it's unlikely they'll cooperate in setting up background tasks (cron jobs) to merge your user tables behind the scenes. (cpanel isn't a technology: it's a system administration user interface provided by hosting vendors who don't trust their customers' skills.)
So. you should design and implement a REST API in the code of both your apps to perform user registration and authentication tasks. You didn't show us the details of your app, so it's hard to design it for you. Still it seems likely you'll have to implement these operations:
PUT user
DELETE user
GET user
POST user to validate a user's password, etc. (Don't use GET to pass secret information: GET request parameters go into server logs.)
PATCH to update details of a user.
If you get the API working, whenever you create/retrieve/update/delete user information in one app, you'll use the API to change it in the other.
Your best bet would be to create a third app just for user management, and have both your existing apps use it. That way you're sure to have one coherent source of truth about users. But you can do it just within two apps.
We are trying to integrate SAP business one to our application using Java
Where can we find more information on it any Documents, API , tutorial, links, how to start/do it pointer towards the right direction will be appreciated.
SAP's Developer portal if more focused on SAP HANA - http://go.sap.com/developer.html?original_fqdn=developers.sap.com
We are considering to use DI server to integrate from the below list?
We cannot use SAP HANA platform.
-DI API,
-DI Server,
-B1WS,
-SAP Business One Service Layer
Thank you for your help and time
The Business One installer has an option to install an SDK component. This contains a CHM format help file containing information on DI-API, DI-Server and UI-API (but not Service Layer which is for Hana version only) as well as database schema. Also in the SDK are example projects in VB and C#.
If you are using DI-Server, calling the GetBusinessObjectXmlSchema method will get you the schema for individual object types such as business partners.
DI-Server is more lightweight but has less functionality than DI-API. It is more suited to transactional processing such as importing orders from a website.
If you do need to use Service Layer, it's functions are based on DI-API and there should be a lot of concepts that apply to both.
B1WS is not stable and has lots of bugs. DI Server is difficult to be integrated with. You could use DI API to do the integration but you have to implement the integration layer with .net platform. Since you need to make the communication work between SAP B1 and your JAVA application, here is another option which should be a feasible solution. Please check the following Python flask RESTful application which is top on SAP B1 DI to enable the RESTful capability for integration with SAP B1.
https://github.com/ideabosque/SAP-B1-RESTful
Here is the detail about how it could be used to integrate between eCommerce and SAP B1.
http://ideabosque.postach.io/post/how-to-use-sap-b1-restful-to-integrate-with-ecommerce-platforms
What is your workflow to integrate between SAP B1 and the JAVA application?
Bibo W.
Di_server is oriented mainly to web products, since it allows multiple connections with one license per server, while di-api is more oriented to desktop applications and uses licenses per user.
This means that with di-server you have a license and can connect multiple users simultaneously, while with di-api you have a license you can only connect one user at a time. Of course you can use a license and manage connection times to users, connected to one and making others wait. Or if you have more di-api licenses connect more users as many licenses as you have. The cost of a di-server license is high, but it is offset against the amount of licenses you would have to buy for di-api by users you want to connect to, if you need them all to be connected to SAP BO.
Backstory
I work for a company that has an online site that allows user to text personal information for collection. We collect the data, and make it available online. Users can choose to share the data with other users.
Going Forward
At some point, this may become classified an FDA-governed medical tool. In anticipation, we'd like to have in place a logging system that shows each time someone accesses our users' data, whether it be the user themselves, another authorized user, or a support person.
Current Architecture
We are currently running Ruby/Rails, and using a MySQL database. The personal information is encrypted in the database.
Data Access for Support
Today, support personnel can access data one of three ways:
admin site The admin site is limited to whatever screens we develop. While we don't currently, we could easily add logging to keep an audit trail of who accessed which data using the admin tool.
sql client I use MySQLWorkbench to access production. However, when connected this way, all personal information (user name, cell number, etc), is encrypted.
Ruby Rails console - Finally, support can log into one of the production boxes and use the Ruby/Rails console from command line. Ruby will decrypt the data, so we can do some simple things such as
u=User.find_all_by_state('active')
and it will return the recordset of all users with state='active', and decrypt their personal information in the resultset.
Holy Grail
logging
easy access for support
I'd love to be have a way to allow easy support access (once authenticated) to the data, but would log everything that is accessed (read or updated). That way, if I'm checking out my buddy's ex-wife's data for example, it gets logged to a place where I can't get in and clean it the audit trail. (See Google firing Gmail employee for an example of employees breaching the data policies).
Anyone have ideas, thoughts, experiences, suggestions with this issue?
hey devguy. This was a issue for me a couple months back. We ended up centralizing our mysql queires so that we could start to track all information coming in and out. Unfortunately the class I wrote is in PHP but the idea behind it could make it very easy to start logging.
https://code.google.com/p/php-centralized-mysql-controller/
Try stored procedures. Make all code use the stored procedures for CRUD activities. This defines an API that your developers can use while business rules are global enforced (don't return entire SSN values, but only last 4 digits, etc).
This serves as the basis for an external API as well.
If you want logging/auditing, you put it in the procedure.
This protects you from everyone except the DBAs.
Background
My research group and I are developing a database to store our data and we are building an software tool that simplifies access to these data. The database will holds data that has been published and that we would like to make available, alongside data that has not been published and that belongs to other researchers.
Objective
We would like for our work to be easily reproducible, and to this extent, we need to allow the public to run SELECT statements on the data. Three possible solutions include:
for each publication, create a subset of the database that can be freely downloaded (possibly in a virtual machine so that the dependencies of the software tool are met)
for each publication, create a many-to-many lookup table that links data records to publications, and then provide public SELECT permissions to access these records. We could easily replicate the database for public use
Parameterization modules
Automation of prior generation
However, I have been told that even allowing wildcard statements compromises security, which is why I consider option 1 more plausible. Option 1 would also enable us to archive the database as it was used with a particular publication.
update: to clarify, I want the users to be able to reproduce the entire computational workflow, which requires using SELECT statements that can join data tables with auxillary data (like covariates, experimental details) in lookup tables.
Question
What is the best way to provide public access to a subset of the database?
You can distribute subsets of data as a SQLite database, that is, create a standalone datafile that people can download to their own computers. Many scholars, economists, etc use SQLite to share datasets because it is self-contained and installation is painless (and I should add, cross-platform).
Create views with appropriate access privileges, and users that can only access these views, but no underlying tables.
We’ll be releasing shortly a companion Rails application to our existing Rails app. We will be running the companion app alongside our existing app on the same servers.
My question concerns the databases. My hosting provider generally would configure a 2nd distinct database for the new application - secondappname_production. However, there are a series of shared tables between the applications. These shared tables are also maintained by a series of cron jobs. I would love to avoid duplicating these tables (and thus the cron jobs) if at all possible.
Is there a way that I can put these shared tables in perhaps a shared database that both Rails apps can leverage? Any suggestions as to how to configure that or documentation pointers?
Thanks so much!
EDIT: To clarify why I don't want to run both apps out of the same DB: Both apps have models of the same name (yet different attributes of the models, etc.), so I would prefer to not run both out of the same DB....
You can have some models in one database (the ones that you want to share), and others in the new app's own database (so they don't collide with the existing app).
To specify a different database for a particular model, try something like this:
class SharedModelBase < ActiveRecord::Base
self.abstract_class = true
establish_connection(ActiveRecord::Base.configurations["shared_db_connection_#{RAILS_ENV}"])
end
Now, use this as a base class for your shared models, and you should be good to go.
Part of your question is best practices, so a couple of other options.
One option is to not even try to access to the db directly, but instead build an integration between the apps using ActiveResource. Have the original app provide a RESTful interface to these tables, and consume it in the new app, and don't share the db at all. I like this option, but may not be clever for your situation.
Another option is to refactor these shared tables into their own database, and have both the rails apps access that db. You could even end up writing services (e.g. restful interface) to this shared data to be used by both apps, and then you are nicely decoupled.
Consider the complexities of when this shared db structure changes. If you are sharing the tables directly, both rails apps could have to be changed simultaneously to accommodate the change - you have linked your release schedule now, these apps are now coupled. If you wrap the access to the db in services, this can provide abstraction as you can serve both the old structure and new structure simultaneously by deploying the new updated service at the same time as the old service interface. It all depends on your app if such complexity is worth it.
I think what you want is share model,not only database table,in rails table is model based.
create main rails app -->rake g model User name:string->rake db:migrate
create shared rails app
-->rake sync:copy
-->(DO NOT generate same model in shared app, also do not db:migrate)
-->config/generater shared
controller and router.rb file(dependend your requirement)
sync.rake(appshared/lib/tasks/)
namespace :sync do
desc 'Copy common models and tests from Master'
task :copy do
source_path = '/Users/ok/github/appDataTester/appmain'
dest_path = '/Users/ok/github/appDataTester/appshared'
# Copy all models & tests
%x{cp #{source_path}/app/models/*.rb #{dest_path}/app/models/}
%x{cp #{source_path}/test/models/*_test.rb #{dest_path}/test/models/}
# Fixtures
%x{cp #{source_path}/test/fixtures/*.yml #{dest_path}/test/fixtures/}
# Database YML
%x{cp #{source_path}/config/database.yml #{dest_path}/config/database.yml}
end
end