|
Is it just me or are the Mobilink docs scattered all over the place? Are the docs on dcx.sap.com the recommended way to get started with Mobilink and then customise it for advanced use-cases? |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 07 Sep '20, 06:34
question was seen: 1,195 times
last updated: 08 Sep '20, 15:07
Well, I was waiting for this question from you. The content on help.sap.com is the same as it was on dcx.sap.com, but it looks somewhat... hm... fat :) I guess Breck can explain better, how he sees the difference. A long time ago he and Volker complained.
Nevertheless, when I was trying to study Mobilink stuff, I was reading tutorials (and doing them): https://help.sap.com/viewer/a09ffd5a93ff477cbcf9d9b1aa4d0801/17.0/en-US/9462b226f4ae48d1a62b16f57209dfdd.html (root link, check the last chapter). It is not a simple technology, because if you click here-and-there, you will mess everything up. But it is not complicated much, after you fix everything what you have messed up before.
When I was studying it, I also read the first chapter in my link: MobiLink synchronization. Just to understand the basics. In few words, Mobilink reads data from consolidated DB and sends it to a mobile device and vice versa. If you generate event handlers using wizards, you might be confused. But if you create every single event manually (execute SQL query, or write a batch file that creates these scripts), you will eventually understand the basics.
And yes... don't start with high availability, secured, user-authentication stuff. I suggest you to start with a simple table, three records, and try to send them to another Ultralite/SqlAnywhere DB.
And yes, start playing with a desktop dev. tools, don't use Android & iOS API.
And another "no", there is no better mobilink docs on Internet. Maybe in one book, but not more.
The documentation on help.sap.com has been updated to reflect software changes introduced since the initial release of SQL Anywhere 17. The dcx.sap.com is no longer updated and is current only to the initial release of v17. The "books" are the same for documentation tools but are organized by topic on SAP Help and by component on dcx with a separate documentation of SA 17 based API documentation. If you have feedback for the documentation team, you can provide comments directly on either site which the documentation reviews and addresses on a regular basis.
Chris, I can see the option to give feedback/comments on dcx.sap.com but NOT not on help.sap.com. Also, if dcx.sap.com is not being updated, wouldn't be a good idea to put a big fat warning message on it?
I just left a comment on https://sqlanywhere-forum.sap.com/questions/35944/mobilink-giving-precendence-to-consolidated-db-during-conflict-handling saying something similar. It seems like apart from the tutorials, a lot of the documentation doesn't mention the Mobilink UI/wizard.
What is the canonical (or recommended) way of configuring Mobilink? Is it via the wizard (which auto-generates a bunch of these scripts), or it is via hand-writing these scripts on your own?
If the wizard is it the preferred way, then it leads to questions like https://sqlanywhere-forum.sap.com/questions/35947/mobilink-recommended-way-to-broadcast-sync-schema-changes and https://sqlanywhere-forum.sap.com/questions/35910/mobilink-changing-a-synchronisation-model-after-it-has-been-deployed -- because via the docs it is not clear to me how the auto-generated scripts are kept up-to-date in the face of an evolving schema?
If hand-writing scripts is the preferred way, then does that mean every single SQL script for every single table has to be manually written by the DBA/user? In which case, what exactly is Mobilink providing (apart from a framework for thinking about this stuff, and some minimal infrastructure for executing these SQL scripts)?
you have to login. Press the icon on top-right corner.
Everybody uses what suits him/her well. I don't write scripts professionally, but I prefer to use the manual way, because this will help you to understand the process better. If the wizard makes a mistake, or does something what is a mystery for you, you will be able to understand this easily. E.g. I was playing with the Java (Direct Row Handling, or Authentication) API, and I liked it.
I am pretty sure, if you are getting familiar with the Wizard, you will be able to achieve your goal faster, but as always, you shouldn't start writing another ERP, and start with smaller/simpler things. And yes... you are right (with the last question). Mobilink is a technology, it is not IDE. You can say the same for other software (e.g. Redis, or even node.js, or Elastic Search), where you see just a command line interface and/or a connection point, and don't even know how to write Hello World.
I am pretty sure, Mobilink tutorials give you some-kind of a good starting point, but the rest you should learn yourself.
But, does the Mobilink UI/Wizard actually work well? For example, it seems to have a specific flow to handle schema changes via
Update Schema Wizard, but when I tried it, I ran into https://sqlanywhere-forum.sap.com/questions/35910/mobilink-changing-a-synchronisation-model-after-it-has-been-deployedWith many years of dev experience on Linux, I'm actually more comfortable with using plain text editors than using graphical wizards. However, the Mobilink tutorials made it sound as if wizard are the only way to get things done.
Is there a tutorial that describes the process of setting up a new Mobilink installation WITHOUT using any graphical wizard?
I have signed-in but still cannot see a way to leave comments. Are you referring to the floating "Feedback" icon?
yes, I am.
> does the Mobilink UI/Wizard actually work well?
The short answer is no.
The long answer is, it does an adequate job for simple setups that don't need ongoing maintenance, but is more trouble than it's worth for complex requirements... and "complex requirements" is the main reason MobiLink is used instead of SQL Remote.
> the manual way ... will help you to understand the process better
Well put! It is critically important to understand how every little detail works in a MobiLink setup, when the time comes for debugging and maintenance.
We do indicate "The latest SQL Anywhere 17 documentation is available on SAP Help Portal".
Thanks. That‘s true. Especially debugging (e.g. if Java/.NET API is used). This is very cool, if you make it work :)