Blog éclectique & sans sujet précis - Mot-clé - Oracle - Commentaires<p>Si ça me passe par la tête, si ça n’intéresse que moi, alors c’est peut-être ici. Ou pas.</p>2024-02-13T09:44:49+01:00L'éditeur est le propriétaire du domaineurn:md5:bf83720a7189bba489682d945b972671DotclearLa Déclaration du Droits du Développeur - Hamzaurn:md5:f270008de556fdda8c86def258610e932018-05-21T07:16:13+02:002018-05-21T12:46:29+02:00Hamza<p>C'est clair que je m'imagine mal trimbaler mon fauteuil de bureau avec massage lombaire chez le client mdr :)<br />
Et possible votre théorie sur le mariage prof/informaticien aha :D</p>La Déclaration du Droits du Développeur - Le webmestreurn:md5:1653026207d8bbaed6b052d236029e2e2018-05-19T12:17:33+02:002018-05-19T11:17:33+02:00Le webmestre<p>@Hamza: PS : pour les profs, je connais le sujet, ce sont même leurs ordinateurs qu'ils doivent acheter (ben oui, ça bosse généralement à la maison, un prof). L'entité locale qui équipe les classes de tablettes inutiles n'est pas leur employeur et donc ne leur paiera pas un PC. Quant à l'administrateur système, c'est bibi. Je pense que c'est une des explications du grand nombre de profs mariées à des informaticiens... :-)</p>
<p>Pour les policiers j'ai entendu le même genre de chose.</p>La Déclaration du Droits du Développeur - Le webmestreurn:md5:ccdede792a2df13fd6bd56e5424007b82018-05-19T12:12:48+02:002018-05-19T11:12:48+02:00Le webmestre<p>@Hamza : oh oui, il est important le siège. Je viens de rajouter un passage sur le sujet, vu que c'est une des causes de mes problèmes d'épaules actuels, partagés par plein de monde.</p>
<p>Autant le clavier ou la souris sont des achats personnels relativement peu coûteux vu l'importance qu'ils ont (et je connais quelqu'un qui exige de pouvoir amener son clavier avec lui), autant amener son siège chez un client est pratiquement compliqué et inenvisageable pour de la prestation. J'ai des collègues qui utilisent même des ballons pour soulager leur dos, cela prêterait à rire dans certains endroits.</p>
<p>La tendance est globalement à l'amélioration mais cela dépend vraiment de l'endroit où l'on se trouve.</p>La Déclaration du Droits du Développeur - Hamzaurn:md5:f7a93b5f89bafaf3f298c165ec14305e2018-05-19T08:04:05+02:002018-05-19T10:42:02+02:00Hamza<p>Pour moi la priorité à toujours été le fauteuil de bureau pour tout ce qui est problème de dos, et j'ai toujours pu exiger d'avoir un truc pas trop dégueu. Pour la souris et le clavier par contre j'ai dans 2 ou 3 boites ou je suis passé du ramener mon propre matos pour gagner en productivité car ils ne voulaient rien entendre. Finalement c'est malheureux mais ça n'a rien d'étonnant, les profs doivent acheter leurs craies, les gendarmes leurs portes-menottes sur aliexpress (témoignage d'un ami lieutenant)... Bref ;-D Vous voyez le tableau</p>Les joies de l’ERP et du CRM (I) - Le webmestreurn:md5:0c9ec21d4766e4a76b3f500bc30a329f2018-05-18T09:17:19+02:002018-05-18T08:17:19+02:00Le webmestre<p>@GRCedric : CDiscount et Leboncoin ont les contraintes des sites très lourdement sollicités, et ont le mérite de viser le simple et efficace pour Mme Michu.</p>
<p>Pour les ERP, il y a eu la contrainte des transitions plus ou moins forcées depuis le client lourd (je crois que SAP en a encore un, qui a le mérite de la réactivité) et de ne pas avoir à changer et revalider une montagne de code mille fois débugué et dont plus personne ne doit savoir comment il fonctionne vraiment. L'ergonomie ils s'en fichent : les personnes sont formées et finissent par prendre leurs habitudes.</p>Les joies de l’ERP et du CRM (I) - GRCedricurn:md5:03f7a4124fa6265be4f0b538d1d76e0e2018-05-18T07:26:56+02:002018-05-18T07:40:56+02:00GRCedric<p>J'aime bien ta 6ème note :) Je les déteste aussi visuellement mais c'est souvent ce qu'il y a de plus efficace !</p>
<p>On peut faire le parallèle avec l'UI de certains sites web. Pourquoi à votre avis des sites comme Leboncoin ou CDiscount gardent leur interface dégueulasse ! Parce que c'est super efficace et plus accessible qu'une interface 2.0 avec du JQuery qui rame.</p>Par paquets de 5 - taryckurn:md5:d5730f0886462d54619b59264f31dbc82011-11-16T15:51:53+01:002011-11-16T15:51:53+01:00taryck<p>Le paramètre par défaut de 5 est dans le paramètre base de donnée : rsdb/max_in_blocking_factor & rsdb/max_blocking_factor<br />
modifiable via RZ11, voir note SAP 881083.<br />
On peut ainsi faire monter pour tout les FOR ALL ENTRIES la taille des paquets de 5 à xx. Chez nous 50.<br />
Pour certaines requettes (celle ou on a la clé primaire par exemple) on peux juger que 50 serait alors trop faible, mais que pour ces requêtes là. On utilise alors le %_HINTS ORACLE avec ;<br />
- '&max_blocking_factor 20&'<br />
- ou '&max_in_blocking_factor 20&'<br />
SAP ne peut être plus puissant que la base de donnée qu'il utilise pour des extractions seules.<br />
Donc dans ton cas :</p>
<pre> SELECT * FROM vbap
FOR ALL ENTRIES IN tab_articles
WHERE vbap~matnr = tab_articles-matnr
%_HINTS ORACLE '&max_in_blocking_factor 500&'</pre>
<p>devrait avoir l'efficacité souhaitée.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:e19b986daf1968df7964216cafd269402010-06-15T19:18:12+02:002010-06-15T18:18:12+02:00Le webmestre<p>@Arialia : Ah, SAP n'a pas le mérite de la souplesse, et surtout veut que tout passe par lui, et à sa sauce. Quant à s'intégrer à l'ergonomie du XXIè siècle… ils savent pas faire.</p>
<p>Au passage, il y a un inconvénient aux jolies interfaces fonctionnelles à façon : elles sont souvent spécifiques, donc soit à maintenir en interne, soit faites par un plus ou moins petit éditeur qui, lui, a forcément d'autres failles, le premier étant le manque de ressources disponibles sur le marché sur son produit (alors que du personnel SAP, chaque SSII en a).</p>
<p>Quant à Ciel ou autres, j'ai lu assez de messages d'horreur à leur sujet, mais je ne connais pas de première main. Ce n'est pas le même marché. Ce qui n'est pas une excuse pour SAP, l'ergonomie est universelle (ou devrait l'être). Mais l'investissement ne se justifie pas puisqu'on vend à des gens qui jugent les fonctionnalités, pas l'utilisation quotidienne (le contraire du particulier ou du petit entrepreneur).</p>
<p>Ah oui : se passer des programmeurs est possible même avec SAP. Mais il faut décider de se limiter à ce que sait faire le produit. Et il faut quand même le paramétrer. Éternel débat entre prêt-à-porter et sur mesure :-) (Réponse rapide : prendre du standard quand ce n'est pas le cœur de métier, faire du spécifique quand on a de bonnes compétences ou que c'est un point qui permettra de se différencier de la concurrence.)</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Arialiaurn:md5:c98c07772b94426fad881c11a71843802010-06-15T11:40:14+02:002010-06-15T10:40:13+02:00Arialia<p>Merci beaucoup pour cet article très intéressant.</p>
<p>Je comprends enfin ce qu'est SAP et plains tout ceux qui ont à migrer des 'ERP' maisons vers SAP, mon mari est dans ce cas et je comprends maintenant son désarroi et celui de ses collègues utilisateurs habitués depuis 2000 à de jolies interfaces fonctionnelles et réalisées en fonction de leurs besoins, tout ça parce qu'un commercial à réussi à vendre SAP à un haut dirigeant qui n'a même pas vu le produit ...</p>
<p>Il m'a parlé des limitations d'interrogation de Sap où tout doît être prévu à l'avance, quelle régression face à la solution SGBDR/application spécifique/Infocentre (Bi-Query ou Bussinessobject avant son rachat)</p>
<p>Si au moins SAP fournissait quelque chose clés en mains du genre les logiciels de Ciel qui aurait permis de se passer des programmeurs , mais c'est apparemment loin d'être le cas ...</p>
<p>Bref quel intérêt de prendre SAP?</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:74944b3819903b0de9d1b920a726cc202010-02-18T18:58:19+01:002010-02-18T18:58:19+01:00Le webmestre<p>@lookcheed : C'est une blague ? L'amoncellement de spécifiques est un défaut propre à l'organisation et non au logiciel. J'ai connu des clients qui avaient tellement patché SAP qu'ils étaient incapables de migrer aux nouvelles versions, il a déjà fallu remigrer à la version classique.<br />
Quand au spécifique buggé, c'est pire sous SAP à cause de ce langage de merde qu'est l'ABAP (y a plusieurs billets sur le sujet).</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - loockheedurn:md5:d2840a61690da860fd709129d480e9992010-02-17T11:59:30+01:002010-02-17T11:59:30+01:00loockheed<p>Oui SAP est destiné au business et pas au developpeur. Au moins avec SAP on se retrouve pas avec une montagne de dev specificique buggé et inexploitable.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Le webmestreurn:md5:c25cc3108f62e016dbc5b9e9fee5d0a92009-12-02T16:02:41+01:002009-12-02T16:02:41+01:00Le webmestre<p>@jhon : Faut savoir lire : je m’étonne que le terme employé par SAP soit une translittération directe du « Abbrechen » allemand (« Interrompre »), traditionnel dans le Windows de là-bas, et non le terme « Annuler » familier aux utilisateurs francophones.</p>
<p>Windows oui c’est mal, mais pour d’autres raisons.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - jhonurn:md5:267c1ee12856b04bbeef1db660f7cf1a2009-12-02T14:04:53+01:002009-12-02T14:04:53+01:00jhon<p>messieu si vous ditez que la reponse ANNULER pour sortir sans rien faire d’une boîte de dialogue cest mal ;;;alors windows cest mal aussi?</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - jhonurn:md5:1a2b2901bbae74dc0c40fe0ab5ff59ea2009-12-02T14:04:51+01:002009-12-02T14:04:51+01:00jhon<p>messieu si vous ditez que la reponse ANNULER pour sortir sans rien faire d’une boîte de dialogue cest mal ;;;alors windows cest mal aussi?</p>La Déclaration du Droits du Développeur - Guillaumeurn:md5:1f608956671e088be8e41c94bac48ed62009-09-13T01:13:10+02:002009-09-13T00:13:10+02:00Guillaume<p>Excellent :)</p>
<p>Je n'ai pas souvenir d'un seul employeur qui m'ait fournit une machine rapide.</p>
<p>Faisons un bilan dans 5 ans... Ces variables d'ordre qualitative seront peut être considérées. . .</p>La Déclaration du Droits du Développeur - Baztouneurn:md5:d4696b9bbcbefac4c8926274a5f9c4472009-09-11T12:16:09+02:002009-09-11T11:16:09+02:00Baztoune<p>Un assez bon résumé des nécessités que j'ai pu ressentir durant mon expérience, bien que limitée. Mais je souhaiterais ajouter, à propos de la connexion internet, que bien qu'il soit nécessaire de filtrer la navigation via un proxy entreprise pour éviter les divagations de certains esprits en mal de divertissement, il devient totalement frustrant de se retrouver bloqué après une journée intensive de recherches concernant un problème quelconque, pour lequel on a du passer par des dizaines de sites qui ont consommé la totalité du quota de navigation alloué...</p>
<p>Certaines entreprises ont en effet une "liste blanche" de sites en accès libre (www.google.*, *.developpez.com etc), une liste noire (youtube etc. -facebook n'étant pas liste noire dans mon entreprise, étonnant et illogique-), et le reste, soumis à un quota (pour ma part appliqué sur 5 jours ouvrés glissés...). On se retrouve très souvent bloqué parce que nos recherches ont abouti sur des sites de cette dernière catégorie (blogs de développeurs etc) ou simplement parce que les images/pdf/sources sont chargées à partir de serveurs miroirs non répertoriés en liste blanche...</p>
<p>Une liste blanche étant très compliquée à gérer (dépend des besoins, parfois ponctuels etc), je suis partisan d'une liste noire bien maintenue (vidéos, jeux flash, réseaux sociaux) et d'un accès libre au reste de la toile. A chacun de se réguler, et de raisonner ses collègues. Ah et puis, pourquoi pas, un accès full-web durant 15/20 minutes à la pause repas, qui contenterait un bon nombre des employés?</p>Les joies de l’ERP et du CRM (II) - Le webmestreurn:md5:0fa95cbe83cd207ca43785f18350e6452009-09-07T20:49:56+02:002009-09-07T19:49:56+02:00Le webmestre<p>@Jérôme F : Oui, l'informaticien de base ne peut dire au client ce qu'il veut. C'est pour cela que le métier de « fonctionnel », plus financier/logisticien/chef de produit qu'informaticien est là : il connaît tout le paramétrage possible (y a des cours pour ça) et comprend les besoins.</p>
<p>Un bon spécifique, oui, il communique par API et par les endroits prévus. Tout gros ERP a des endroits privilégiés pour cela, plus ou moins intrusifs.</p>Les joies de l’ERP et du CRM (II) - Jerome F.urn:md5:c6751b008a1f1c1f8d64c26ca16ecc182009-09-07T17:45:10+02:002009-09-07T16:45:10+02:00Jerome F.<p>"soumettre l'entreprise à la logique de l'ERP"<br />
Ca c'est une bien mauvaise idée : l'informaticien (et consultant) que je suis est incapable de dire au responsable logistique, production, commercial,... comment ils doivent travailler. C'est pas crédible. C'est le genre de situation que j'ai du mal à supporter.</p>
<p>"Je n'en ai vu aucune SANS spécifique."<br />
Mette du spécifique dans l'ERP c'est pas forcement la meilleure solution. Le spécifique interfacé avec l'ERP mais hors ERP, partageant dans l'idéal la base de données (en écrivant dans les tables de l'ERP via des APIs) c'est plus souple.</p>
<p>"automatiser les tâches répétitive, (rôle de l'informatique en général)" 100% d'accord avec vous.</p>Les joies de l’ERP et du CRM (II) - Le webmestreurn:md5:d848a3cc262332b2c460eff521a0d2b12009-09-05T11:54:45+02:002009-09-05T10:54:45+02:00Le webmestre<p>@Jerome F : Quoi qu'en disent les commerciaux, un ERP ne sait pas tout faire, vu que chaque entreprise a ses habitudes, ses combines, sa tradition, et des clients qui ont aussi les leurs. Il y a aussi ce qui possible manuellement, et ce qu'on aimerait bien automatiser selon des règles maison.</p>
<p>Éternel dilemme : soumettre l'entreprise à la logique de l'ERP ou patcher l'ERP pour l'adapter à l'entreprise ? Parle-t-on paramétrage (SAP est le roi) ou programme spécifique ? Un spécifique doit être maintenu à chaque migration et est une nouvelle source de bugs. J'ai vu une société qui avait tellement amendé SAP qu'elle était devenue incapable de migrer à la version suivante. Je n'en ai vu aucune SANS spécifique.</p>
<p>À la base je dirais que les spécifiques doivent :<br />
- automatiser les tâches répétitives qui ne le sont pas déjà (rôle de l'informatique en général) ;<br />
- porter sur le cœur de métier, les spécificités de l'entreprise, ce qui fait sa valeur ajoutée : par exemple une entreprise de logistique mettra sa compta dans l'ERP, mais créera ses propres logiciels logistiques.</p>Les joies de l’ERP et du CRM (II) - Jerome F.urn:md5:ef0ab81e36a6210b987236f6787671832009-09-05T11:23:19+02:002009-09-05T10:23:19+02:00Jerome F.<p>Travaillant dans le domaine des ERPs des problèmes de ce genre j'en vois souvent. Les clients ont des processus très complexes et espèrent sérieusement les gérer avec un logiciel standard.<br />
Souvent la solution de loin la moins chère à ce type de besoin c'est le développement spécifique d'un programme hors de l'ERP. Mais cela casse le principal argument de vente de ces usines à gaz : elles sont sensées tout faire.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:ffacb5042683ff8c4abacbf2682a359a2009-06-13T20:26:43+02:002009-06-13T19:26:43+02:00Le webmestre<p>@renommeur : Condoléances. Perdre 2 ans de vie à ce genre de choses, j’aurais pas supporté. J’espère que ton système est réutilisé ailleurs...</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - renommeururn:md5:7f9e6c66804bbe6ee2a1f5cd2bb0e6752009-06-13T11:00:59+02:002009-06-13T10:00:59+02:00renommeur<p>J'ai passé mes deux dernières années de ma vie à renommer environ 16000 comptes utilisateurs SAP sur 70 systèmes et 220 mandants. Car le nom d'utilisateur est en même temps sa clé. Il y a environ une quarantaine d'objets liées à cette clé, dont un bon nombre en 1:1 (et non pas 1:n ce qui rendrait la tâche plus simple). J'ai donc développé une solution en ABAP qui gère le processus de renommer un utilisateur, y compris la génération et l'envoi d'email de son nouveau compte et mot de passe avec un message en la langue de l'utilisateur.... je migre les favoris, variantes ALV, variantes programmes, parametrage du workbench, L'infotype 0105/0001, le business partner (à travers la central person), planstellen, autorisations etc. etc. Donc j'ai du boulot grâce à SAP! Mais je suis d'accord que tout cela aurait était trivial si SAP avait un identificateur technique distincte du nom d'utilisateur... si vous voulez renommer vos utilisateurs et en passant faire de l'ordre dans ces comptes - contactez moi...</p>Crise de nerf avec Oracle - Le webmestreurn:md5:e9ee31b28e597ae0984a8686b80ea3212009-05-13T19:05:13+02:002009-05-13T18:05:13+02:00Le webmestre<p>@fred : Merci pour la pro­po­si­tion d’aide mais ça va mieux main­te­nant. Ora­cle, ce n’est pas moi qui l’ait choisi pour mes pro­jets actuels, il est sou­vent là « par défaut », et il n’y a que les tech­ni­ques qui voient le coût en admi­nis­tra­tion.</p>
<p>Pour moi, le max de con­fort était atteint avec Ora­cle 9i. Base légère pour les machi­nes actuel­les, avec les fonc­tion­na­li­tés qui vont bien pour ce que j’en fait, Post­greSQL voire MySQL suf­fi­rait tout autant. OEM per­fec­ti­ble mais accep­ta­ble.<br />
Tan­dis que la 10g, si on ne décide pas d’en faire son métier et d’inves­tir en temps (et on l’impute sur quoi ?) et en matos (mon Dieu que ça mange !), on peut sale­ment mor­fler. Quant à l’inter­face d’admin web, elle a le mérite d’exis­ter mais quelle lour­deur…</p>Crise de nerf avec Oracle - fredurn:md5:47c572f91a038c4f4cf4b4a67d2ec94e2009-05-13T11:48:51+02:002009-05-13T10:48:51+02:00fred<p>DBA, c’est un métier…<br />
Je gére 200 bases 9i/10g sur une qui­zaine de ser­veurs (win­dows/aix). J’uti­lise Ora­cle Entre­prise Mana­ger (GRID) pour la super­vi­sion de tout ça, en deux ans et demi, je n’ai pas vu une ins­tance tom­ber.<br />
Une fois la pre­mière base 10g créée, je recom­mande d’uti­li­ser des copies de la base et la retailler (ou gar­der une ins­tance mini­male vide en backup), plu­tôt que d’uti­li­ser l’assis­tant de créa­tion de base est péni­ble…<br />
Il y a des bases avec des con­fig tor­dues, :<br />
- une base avec 400.000 par­ti­tions (c’est énorme…), elle pose des pb pour la col­lecte des sta­tis­ti­ques, obli­ger de desa­sem­bler des vues sys­tè­mes et de lan­cer le cal­cul en paral­lèle sur 8 pro­ces­seurs dans des jobs qui se repar­tis­sent les tables à ana­ly­ser pour avoir des perfs inte­res­san­tes…<br />
- des bases répli­quées (data­guard), facile à met­tre en oeu­vre en 9i, très com­pli­qué à faire évo­luer vers 10g sur aix, grosse galère, même avec le sup­port gold 24/24… Mais après 3 semai­nes de galère, plus aucun pro­blème avec et une doc de 80 pages pour tout expli­quer et docu­men­ter tou­tes les erreurs ren­con­trées…. Main­te­nant, on l’oublie et tout se déroule sans pro­blème en switch over ou fai­lo­ver<br />
- une base qui gros­sit de 1% par jour (4 à 5Go par jour) qui final­le­ment tourne bien après quel­ques sou­cis de migra­tion de 9i vers 10g : le moteur géné­rait quel­ques mil­lions de requê­tes inter­nes par seconde sur la base… (le petit IBM P570 avec une DS8000, 8 procs et ses 45Go de RAM dépote pas mal…)<br />
- l’accès con­trô­lés par ligne d’une base par­ta­gée par plu­sieurs clients qui n’ont pas le droits de voir ou modi­fier les don­nées des autres, via le Vir­tual Pri­vate Data­base (VPD, FGA), pas de sou­cis, les docs sont bien fai­tes.<br />
- évi­dem­ment il vaut mieux Ora­cle sous Unix que sous Win­dows parce que l’OS est pourri et faire des devs pro­pres sur un sys­tème pourri c’est un peu comme cons­truire des tours jumel­les sur un maré­cage (au moin­dre avion qui passe, ça tombe). Les reins­tall suc­ce­si­vent peu­vent pour­rir les assis­tants, sur­tout si elles n’abou­tis­sent pas, sous Unix, 0 sou­cis.<br />
- dom­mage qu’Ora­cle a écrit les agents en Java, parce que c’est vrai­ment une daube ce lan­gage au niveau perf et uti­li­sa­tion de res­sour­ces. Avec une qua­ran­tai­nes d’ins­tan­ces sur le ser­veur, on passe son temps à super­vi­ser et ne rien faire… heu­reu­se­ment WLM est là pour limi­ter les res­sour­ces uti­li­sées par les pro­ces­sus.</p>
<p>En CCL, avec de la pra­ti­que et en trai­nant sur les bons forums, on peut s’en sor­tir haut la main. Enfin, choi­sir Ora­cle, c’est choi­sir la Rolls, au prix ou ça coute, faut pas l’uti­li­ser pour des bases qui tien­nent dans la poche.<br />
Si vous avez des sou­cis avec, je peux aider :-)</p>Par paquets de 5 - Le webmestreurn:md5:04cbb750a85d5b27017b33e5888837fd2009-03-12T21:46:03+01:002009-03-12T21:46:03+01:00Le webmestre<p>@taryck : Oui, en gros c’est le problème : le SQL généré par l’ABAP est « basique » et ne tient pas compte de la puissance de la base sous-jacente et la sous-utilise…</p>Par paquets de 5 - taryckurn:md5:e94646a39c8623655cbb41cb66a15c592009-03-12T18:04:26+01:002009-03-12T18:04:26+01:00taryck<p>Je pense que le point qui a été “zappé” est simplement que le code SQL en ABAP est de l’OPEN SQL transcrit en SQL-Natif Oracle, mais pas seulement. Il est donc possible que certaines limites présentes sur les autres BdD supportées par SAP amène à cette limite constatée de 5 clés.<br />
Même si je n’ai aucune idée de la raison…</p>Crise de nerf avec Oracle - Le webmestreurn:md5:2eee4ba3f76b256d1ee3e6461141a3082009-03-03T20:25:56+01:002009-03-03T20:27:33+01:00Le webmestre<p><b>@Casimir-le-troll </b> : Si tu crois que c’était la première base que j’ai installé à l’époque… Suivre l’assistant pour installer des bases vierges, tout le monde peut le faire. Et oui, j’ai eu les formations, et oui j’ai lu les docs (comme tu ne l’as pas lu ci-dessus). Mais les vraies merdes n’arrivent que dans les configs bizarres, avec de l’historique, et c’est là qu’on voit la *vraie* solidité des softs d’installation - et de désinstallation. En l’occurence, c’est la cata : la machine qui fige, les fichiers de config éparpillés ou les messages d’erreurs absents, c’est dans le soft, pas ailleurs.</p>Crise de nerf avec Oracle - Casimirurn:md5:65ffcd3ac30be500f5be7917dee2545c2009-03-03T14:57:00+01:002009-03-03T14:57:00+01:00Casimir<p>Super, le mec qui n’a suivi aucune formation Oracle, n’ pas pris la peine de se documenter sur la méthode d’installation, etc., qui espère réussir une installation “au feeling”, qui bien entendu se plante et au final nous sort “Oracle c’est une bouse”. C’est étonnant, mais moi qui ai suivi une seule formation Oracle et ai pris la peine de me documenter, j’ai réussi à faire cohabiter Oracle 9i, 10g et 11g sur une même machine, sans aucun souci.<br />
Parfois, le problème n’est pas dans le logiciel, mais plutôt entre la chaise et le clavier…</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:ad834af6e825cd862c18101f8d24ae132009-01-27T15:12:51+01:002009-01-27T15:12:51+01:00Le webmestre<p>@FrédéricLN : Focalisé sur les données ? On va souvent être d’accord alors, j’ai une vision des choses très orientée « SQL über alles ». Voir notamment le tag « SQL » à gauche.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - FrédéricLNurn:md5:5466f39f836d8bcd4e162d9dca0ff2532009-01-25T19:10:48+01:002009-01-25T19:10:48+01:00FrédéricLN<p>Bonsoir et… merci. Formé aux SGBD il y a plus d’une décennie, j’avais entrepris de me remettre à jour avec des bouquins, mais on en apprend bien plus et bien plus vite sur ce blog ;-)</p>
<p>(PS - je sais bien que pour former un développeur, ce blog ne suffirait pas tout à fait, mais mon ambition est plus modeste, niveau utilisateur éclairé, focalisé sur les données elles-mêmes).</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - akounturn:md5:ee947a5e5e7a85e0640bdd7abba0689a2009-01-18T20:48:46+01:002009-01-19T20:24:29+01:00akount<p>vos conseils sont benefiques et interessants merci</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - sara saraurn:md5:b2410a7d1a4ee6f24ff53ab9d25754902008-06-07T14:30:51+00:002008-06-07T14:30:51+00:00sara sara<p>bonjour tt le monde<br />
<br />
En fait, je suis actuellement en phase de fair une etude de la mise en place de SAP dabs une soété industielle.et je voudrais bien que qlq'un maide à trouver une documentation sur les differents types de SAP.Mon mail est le suivant : <a href="mailto:suplaylogistic@gmail.com" rel="ugc nofollow">suplaylogistic@gmail.com</a> <br />
<br />
Merci d'avance<br />
</p>Service après-vente - Momourn:md5:3adb1814a623cffea4b0a28a613b38502008-06-02T14:42:45+00:002008-06-02T14:42:45+00:00Momo<p>Purée qu'est-ce que Vista a réussi à se faire désirer ! J'ai acheté mon PC peu après sa sortie, en me débrouillant pour avoir xp (mais en me disant "c'est beau vista")... 3 mois après j'installais Ubuntu, 1 mois après je tombe sur la démo de Beryl. j'ai évité une belle bétise ^^</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - ilouisurn:md5:075050e2bb55fb9d3cc5ae42f71724e42008-06-02T12:17:55+00:002008-06-02T12:17:55+00:00ilouis<p>je suis administrateur des bdd oracle, j aimerai juste ajouter le point suivant:<br />
vous parlez plus sur les interfaces et design mais je croix que le plus important c la cohérence des données, la sécurité des données, la lecture et la fiabilité de votre information (rapports, recherches, statistiques, etc.) <br />
Des procédures exemplaires, bien planifiées, bien conçues et bien communiquées favorisent l'intégrité de l'information.<br />
eeeeeeeet je pense que oracle reste le meilleur de tout ça .<br />
<br />
merci</p>Crise de nerf avec Oracle - Koklikourn:md5:0316bb19766e8575157cdbb6114c61422008-02-19T14:42:30+00:002008-02-19T14:42:30+00:00Kokliko<p>+1000<br />
oh oui que c'est une bouse cet Oracle, ses installations de m*$ù*, son Oracle_home que je n'ai toujours pas compris, son tnsnames.ora, etc... !</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Le webmestreurn:md5:76360a0f97a897c380b510393fe603742008-01-29T22:42:09+00:002008-01-29T22:57:47+00:00Le webmestre<p><b>@Petergun_1</b> :À propos de l’interface : Dieu merci, elle n’est PAS ludique ! Mais elle est moche, sous SAP ou Oracle Appli. Et pas du tout ergonomique par pas mal d’aspects. Après, on peut pinailler sur tel ou tel point mais il est indéniable que ce n’est pas le souci majeur des éditeurs. Il y a des progrès avec le temps, et éventuellement des régressions. Et je suis d’accord pour le processus qui est ce qu’il est, mais la limite n’est même pas là, rien de ce que j’ai évoqué ci-dessus n’aa à voir avec des limitations fonctionnelles !</p>
<p>Pour les produits cartésiens sous BO, c’est un problème complètement différent (et BO ne se sent vraiment bien qu’avec un <i>datawarehouse</i> alimenté par derrière dont le schéma de données est incompatible avec celui d’un ERP optimisé pour du transactionnel. Je sais, ce n’est qu’un exemple, mais il est mauvais. Sur le principe je n’ai rien contre les ERP, au contraire, c’est l’implémentation qui pêche (surtout du point du développeur et surtout sur SAP...)
<p>À propos des petits éditeurs : il est vrai qu’un petit éditeur, aussi talentueux soit-il, aura du mal à répondre au cahier des charges s’il faut supporter 20000 points de vente dans 200 pays et 50 langues...La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Petergun_1urn:md5:f4aec2ecd958cc7ccf24605db47747a62008-01-28T17:19:29+00:002008-01-28T17:19:29+00:00Petergun_1<p>Oups j'ai omis de laisser mon mail pour signer mon précédent roman qui à mon regret, dsl, comporte bcp de fautes... ah qd la passion aveugle ;)<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Petergun_1urn:md5:597db747fca5971493946d301b7d598f2008-01-28T17:06:22+00:002008-01-28T17:06:22+00:00Petergun_1<p>Bonjour,<br />
<br />
Pour ma part, je suis consultant SI Oracle Financials et j'ai travaillé par ailleurs sur SAP auparavant lorsque j'étais contrleur financier.<br />
<br />
Je vous rejoints sur certains points et évidemment m'éloignerai sur certains et tant qu'à faire, je m'éloignerai en évoquant d'autre -/+...<br />
<br />
1/ Je vous rejoints sur......... mais.........!<br />
<br />
- L'interface, de manière générale et quelque soit les produits R/3 ou EBS, ou encore JD Edwards, cela ne brille pas une interface magnifique truffée d'animation flash, de photos de vacance et j'en passe et des meilleurs décoration. Mais je reconnais que travailler avec une interface visuelle agréable, ergonomique, ludique devrait être davantage pris en compte par les développeurs/éditeurs.<br />
- Les restrictions, là je vous rejoint sans vous rejoindre: oui il y a de nombreuses restrictions, mais celle-ci sont le reflets du paramétrage soit imposé par la "business line" client (exemple: un workflow d'approbation multi-niveaux à développer, des process internes figés nécessitant d'adapter l'outil au besoin et non l'inverse à savoir l'organisation à l'outil). Je suis le premier à dire que l'outils est imparfait et que mettre en place un ERP implique souvent plus qu'un équilibre entre adaptation au nouvel outils et adaptabilité de l'outil avec le Business. Dans bien des cas (la majorité) on espère que le client va s'adapter à l'outils et refondre nombre de ses processus. La réalité saute vite au yeux: les raisons sont nombreuses / politique / entreprise client vieillissante (je ne prétendrai aps qu'il faille mettre à la porte les récalcitrants pollué par leur système qu'ils ont utilisé durant 30 ou 40 ans... mais un minimum d'ouverture et de flexibilité est une condition de la réussite de l'implémentation...<br />
<br />
Bref pour réusmé ces 2 idées : l'interface n'est pas le fort de ces outils ce qui n'empêche pas une certaine flexibilité pour s'adapter au besoins. Flexibilité ne rimant pas avec 0 limite, ces limites sont souvent issues de la rigidité des process client avant tout. Maintenant la rigidité de base du système est aussi une volonté de cadrer l'utilisation. Un projet ERP réussit est un projet ERP pour lequel le client aura compris que même si quelques besoins spécifiques peuvent être satisfaits, il devra s'adapter à un outils fourni de bases avec des fonctions standards répondant à 80-90% de ses besoins. Les 10-20% étant la part de contingence dédié au développement support...<br />
<br />
La réalité saute vite aux yeux... la tendance 80/20 est plus du 65/35...mais bon...<br />
<br />
Maintenant je m'éloigne et ne suis plus trop d'accord / lol<br />
<br />
- un ERP est comme une toile d'arraignée : un noyau central autour duquel gravites des modules complémentaires ou non, reliés directement ou indirectement. L'objet est de créer un réseau multi métiers sur une seule toile avec comme finalité de pouvoir croiser les données et éviter ce que vous voyez tout le temps en travaillant avec Business Object lorsqu'un univers est mal paramétré: Erreur/ Calcul cartésien!!!!!!!! insupportable je peux vous l'assurer...<br />
Tout cela pour dire cet outils sur lequel nous passons des savons sur ce débat à une vertue: la rationalisation des process et cela on ne peut lui enlever.<br />
<br />
- Maintenant oui la concurrence est limitée : 2 éditeurs et cela est regrettable même si avant il y en avait potentiellement d'autres (SAS, etc...) le choix est encore une fois : politique mais aussi stratégique. Faire appel à un petit éditeur lorsque vous vous appeler Total et que vous devez déployer X licences est une impossible pour toutes les raisons que la logique emporte. <br />
<br />
Bon c'est sur, un bon ERP ne vendra pas sans approbation multi niveau pour 4,7 milliard d'€uros les positions de la Société Générale ;)<br />
<br />
Bien à vous pour d'autre aventure ERP iterrative ;)</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - jeromeurn:md5:a5f4a435f186ba64cc57663b588950012008-01-13T10:15:10+00:002008-01-13T10:15:10+00:00jerome<p>Bonjour,<br />
<br />
je suis comme toi Hora, je redige une thèse aussi sur les ERP peux tu prendre contact avec moi j'aimerais discuter avec toi des ERP et te poser quelques questions.<br />
<br />
Cordialement jerome</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - horaurn:md5:42ae577b7d57170b59f0161e7e99d2dc2007-12-19T14:19:13+00:002007-12-19T14:19:13+00:00hora<p>Bonjour,<br />
Je trouve votre article très intéressant, d'autant puisque je rédige actuellement une thèse sur les ERP et leur impact au plan organisationnel.<br />
J'ai cherché vos cordonnées sur le blog mais pas trouvé.<br />
Est-il possible de vous rencontrer pour un entretien ayant pour but d'approfondir le sujet, notamment par rapport à la philosophie (différente) de ces ERP, au plan méthodologique, des processus métiers, etc...<br />
Vous remerciant d'avance,<br />
Cordialement</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Gurn:md5:be9df4dd0c1a048c901b12af2c9e7ec52007-12-09T12:07:29+00:002007-12-09T12:07:29+00:00G<p>Bonjour,<br />
Je n'ai pas d'expérience dans les ERP mais j'ai trouvé cette petite video qui reprend vos idées sur Oracle et SAP.<br />
Cette pub a été faites par Lawson, un autre editeur de solution ERP :<br />
<a href="http://www.dailymotion.com/relevance/search/lawson/video/x32dmt_pub-lawson-chat_ads" title="http://www.dailymotion.com/relevance/search/lawson/video/x32dmt_pub-lawson-chat_ads" rel="nofollow" rel="ugc nofollow">www.dailymotion.com/relev...</a><br />
En tout cas, merci pour votre retour d'expérience :)<br />
G</p>Les joies de l’ERP et du CRM (II) - anteaneurn:md5:c4ff88c8521bc1974d27a04329cb7a122007-12-06T19:22:30+00:002007-12-06T19:22:30+00:00anteane<p>Je reviens sur ce post ou j'avais ecrit ce petit billet pour vous dire que nous avons mis en ligne un article traitant de la rédaction d'un cahier des charges gpao avec un exemple complet de cahier des charges à télécharger :<br />
<br />
<a href="http://www.anteane.fr/index.php/GPAO-et-pmi-soft/Rediger-un-cahier-des-charges-pour-un-logiciel-de-gpao.html" title="http://www.anteane.fr/index.php/GPAO-et-pmi-soft/Rediger-un-cahier-des-charges-pour-un-logiciel-de-gpao.html" rel="nofollow" rel="ugc nofollow">www.anteane.fr/index.php/...</a></p>La Guerre des ERP : SAP vs Oracle Applications (4) : Philosophie opposées - Le webmestreurn:md5:dd021c3ac1cfef245124559ffb244bfc2007-10-05T20:17:20+00:002007-10-05T20:17:20+00:00Le webmestre<p><b>@Vincent</b> : Oui, tu as raison ! J‘ai confondu parce que MySQL a bien participé au développement, mais Adabas/MaxDB est bien plus ancien. Je corrige. Merci !</p>La Guerre des ERP : SAP vs Oracle Applications (4) : Philosophie opposées - Vincenturn:md5:3672d4b8474854f1add0b1c23e0bc84e2007-10-05T11:09:08+00:002007-10-05T11:09:08+00:00Vincent<p>Attention, mySQL et MaxDB sont bien deux bases de données distinctes. La seconde, initialement connue sous le nom de SAPDB, est distribuée sous forme de partenariat entre SAP et mySQL. Il semblerait d'ailleurs aux dernières nouvelles (sept 07) que SAP ait repris la main sur MaxDB, indépendamment de mySQL.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - LDEurn:md5:34335855d5320d93aa667fd512b25cef2007-10-02T18:06:05+00:002007-10-02T18:06:05+00:00LDE<p>Bonjour <br />
Soit SAP n'est pas une modèle d'ergonomie mais l'outil évolue (en 1998 on était en version 3.1 qui je vous l'assure ne ressemble pas du tout aux copies d'écrans des version 4.6 et suivantes)<br />
<br />
De plus SAP "embarque" en lui un outil de modificétaion d'écran plutôt bien fait : le GUIXT avce lequel vous pouvez redisgner vos écrans (transformer des listes en boutons radio, créer de nouveaux boutons pour des chainements d'écrans...)<br />
<br />
J'essayerai de faire à l'occasion un post sur ce sujet <br />
<br />
A bientôt<br />
<br />
</p>Par paquets de 5 - Le webmestreurn:md5:a72d893d426c79f15a6ed7642adac2722007-09-14T07:39:34+00:002007-09-14T07:39:34+00:00Le webmestre<p>@ECIR : Le SELECT...ENDSELECT, c'est ce que j'utilisais justement... Quant aux jointures, évidemment, comme en SQL il vaut mieux tenter de tout faire en une seule requête. Par contre c'est loin d'être toujours possible, et l'ABAP n'a pas la souplesse du SQL quand il s'agit de faire des « requêtes de feu » (écrire à la main des requêtes SQL de 2 pages avec 5 niveaux de sous-select ne me fait pas peur, donc je suis assez exigeant sur le sujet, mais quand même).</p>Par paquets de 5 - ECIRurn:md5:7ee7bdd172496ab4a1f2db1145a3ce6f2007-09-13T22:03:40+00:002007-09-13T22:03:40+00:00ECIR<p>Bonsoir,<br />
<br />
remarque pertinent du webmestre: le FOR ALL ENTRIES découpe les requêtes par plage de 5 valeur contenues dans la table interne. si la table interne contient 2000 enregistrements, il y a aura donc 400 requêtes SQL exécutées.<br />
<br />
Il y a plusieurs solutions possibles:<br />
- utiliser le select ... endselect, tel que c'est recommandé dans la transaction SE30<br />
- utiliser les possibilités de jointures, de sous-requêtes<br />
<br />
(:))</p>Par paquets de 5 - Le webmestreurn:md5:ec2b362544799e13bd2dd6b69334c9852007-07-22T19:42:49+00:002007-07-22T19:43:18+00:00Le webmestre<p><b>@bob</b> : Et non, il fait 5 fois moins d'accès en base que de WRITE (de lignes ramenées), mais c'est encore beaucoup trop, et c'est bien ce que je lui reproche. <br>Au lieu d’une requête dont chaque ligne est utilisée (bête curseur), il crée une requête <i>différente</i> pour cinq lignes de paramètres !<br>Qu’une table interne permette de contourner/éviter le problème, pourquoi pas (et ce serait après tout la moindre des choses), mais ce n’est pas forcément possible ou souhaitable, et de mon point de vue cela en rajoute encore dans la lourdeur de programmation (alors que le SELECT...ENDSELECT a le bon goût d’exister).Par paquets de 5 - boburn:md5:ae3254c341b086b01de66f2b72638c732007-07-19T15:17:13+00:002007-07-19T15:17:13+00:00bob<p>le prob, c'est que tu fais autant d'accès en base que de write ...<br />
<br />
essaye plutôt ça avant de critiquer un langage que tu ne connais pas !<br />
DATA : matable TYPE TABLE OF vbap WITH HEADER LINE.<br />
<br />
SELECT * FROM vbap<br />
INTO TABLE matable<br />
FOR ALL ENTRIES IN tab_articles<br />
WHERE vbap~matnr = tab_articles-matnr.<br />
<br />
LOOP AT matable.<br />
WRITE :/ matable-matnr, matable-vbeln, matable-posnr .<br />
ENDLOOP.</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - urainienurn:md5:c872227ca4228d131518394969bf9d2f2007-06-25T11:09:08+00:002007-06-25T11:09:08+00:00urainien<p>Bonjour,<br />
<br />
Pour cléopatre et les autres, allez sur www.fnac.com, mon livre est en prévente. Méthode de formation sur l'ABAP, en français. Méthode éprouvée depuis 3 ans, et avec les remerciements d'une grande SSII.<br />
Le titre est SAP et ABAP, aux éditions ENI. Un accès est sur mon site.<br />
Pour ceux qui le souhaitent, j'ai mis en place des forums sur l'ABAP, une base de connaissance sur l'ABAP, le tout en accès libre.<br />
<br />
Cordialement,<br />
<br />
Yann SZWEC<br />
<br />
PS : mon objectif n'est pas de convertir le webmestre à l'ABAP (:))</p>Les joies de l’ERP et du CRM (II) - Nicolas MARTINurn:md5:f03486c05d1dbb379363af91fe63ae4f2007-05-10T14:24:36+00:002007-05-10T14:24:36+00:00Nicolas MARTIN<p>il semblerait que <a href="http://www.anteane.fr/dotclear/index.php?q=erp+gpao" title="http://www.anteane.fr/dotclear/index.php?q=erp+gpao" rel="nofollow" rel="ugc nofollow">www.anteane.fr/dotclear/i...</a> fonctionne...</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Heptaeonurn:md5:27a0cb41bb5b8bd3d2fc47ef21ce980a2007-05-08T21:52:02+00:002007-05-08T21:52:02+00:00Heptaeon<p>Je suis a 100% de ton avis. SAP a la même politique que IBM avec ses mainframes. On sais comment ça a terminé. <br />
<br />
De mon coté je cherche l'ERP qui remuera les hautes sphères. Un ERP saint et clair (de conception), Ergonomique et Accessible, avec des technologie d'avenir, qui ne font pas de protectionisme sur l'information, et qui ont une politique commercial du win/win plutôt que de la sangsue. <br />
<br />
ps: Pour ceux qui diront que SAP ne disparaitra jamais, je leur dirais que certaine société sont toujours sur mainframe. </p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - Le webmestreurn:md5:d852f896d25bad19671cf53689d5bfb62007-04-19T18:58:34+00:002007-04-19T19:05:25+00:00Le webmestre<p><b>@montana</b> : C’est une bonne remarque, mais je ne l’ai jamais vue, cette version. Je peux juste répéter l’avis d’un collègue qui a développé dessus : c’est totalement inflexible, pas customisable, inadapté pour une SSII qui aime facturer du conseil (et tant mieux pour le client :-). Et un commercial m’a dit qu’il avait du mal à le vendre : « SAP » est une marque qui fait <i>peur</i> aux PME.</p>La Guerre des ERP : SAP vs Oracle Applications (1) : Des interfaces hideuses - montanaurn:md5:93e1f29b84561166af4f138da9a7e0272007-04-19T12:17:17+00:002007-04-19T12:17:17+00:00montana<p>Vos informations sont correctes et très instructive mais il serait intérréssant de se pencher sur la version déstinée au PME de SAP: Business One. Elle est nétement plus simple d'utilisation et beaucoup plus finie.</p>Service après-vente - Eric C.urn:md5:6969ab46dd6f57df9f4f306677e5ca632007-04-16T10:50:05+00:002007-04-16T10:50:05+00:00Eric C.<p>Une preuve que la veille bloguesque (à ne pas confondre avec la vieille blogueuse) sert à quelque chose : le billet d'Eolas m'avait échappé.<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:8899ce905d0319a93e553af99dfb2bd02007-02-26T19:14:08+00:002007-02-26T19:14:08+00:00Le webmestre<p><b>@cleopatre</b>: En français ??? Heu... Désolé, j'en connais pas. De toute façon dans ce métier faut savoir acheter en anglais voire ici en allemand... </p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - cleopatreurn:md5:4a1c08a19d3c3c5db4f3da76357358242007-02-25T22:35:09+00:002007-02-25T22:35:09+00:00cleopatre<p>bonjour, je recherche un livre en francais pour Abap.Merci d'avance j'en ai vraiment besoin.à bientôt.</p>Des millions de lignes à travers le millefeuille - UKRAINIENurn:md5:d5ecf17f1f5056854df26457b7563e012007-02-14T11:07:47+00:002007-02-14T11:07:47+00:00UKRAINIEN<p>Remerciement partagé. J'aurai aussi appris.</p>Des millions de lignes à travers le millefeuille - Le webmestreurn:md5:be7e030ca9e38156a130e1dd240235f62007-02-13T21:19:17+00:002007-02-13T21:21:22+00:00Le webmestre<p><b>@UKRAINIEN</b> : <br>- Quitter SAP ??? Le choix d’un ERP ne se remet pas en cause à la légère, quel que soit le coût de la licence : le tarif de la migration (que ce soit d’Oracle Applications vers SAP ou l’inverse) est prohibitif, avec tous les spécifiques et interfaces à réécrire, les flux métiers à revoir (et Dieu sait qu’un ERP est structurant de ce point de vue...). Ça n’est envisageable sérieusement qu’en cas de dépérissement de l’éditeur de l’ERP originel ou de consolidation de plusieurs ERP après fusion de deux entreprises...). Le prix des licences est un détail à côté du coût d’implémentation et de maintenance. (Même si ça se rentabilise, mais c’est vrai pour la plupart des ERP).</p>
<p>- Le lien avec le dictionnaire de données a ses côtés pratiques, et n’est pas trop mal implémenté (pour du SAP), mais d’un autre côté mélanger allègrement le technique et le fonctionnel n’est pas non plus une si bonne idée, les contraintes au développement sont parfois assez pénibles. Dans R/3, passe encore, mais en ABAP objet, les problèmes de transtypage que je citais étaient inconnus dans aucun autre langage, forçaient à une orgie de transtypage manuel et surtout n’étaient pas repérés à la compilation mais faisaient dumper à l’exécution !
<p>- Le SQL de SAP n’a pas de syntaxe si particulièrement spéciale (sinon ces pénibles histoires de parenthèses et de virgules, il est SURTOUT très limité par ce qu’on peut faire faire à la base (sauf à faire du SQL natif mais dans ce cas pourquoi acheter SAP ?).
<p>- Les tables internes ne sont pas trop mal gérées mais le problème est leur existence même : sous Oracle, l’utilisation des tables « en direct » (ou par des fonctions d’API) était tout aussi pratique - mais on tirait parti de la gestion des commit, des curseurs, du fait que les SELECT pouvaient être beaucoup plus complexes. Et cela faisait un code nettement moins verbeux (moins de lignes par tâche, quoique cela dépende pas mal du développeur).<br>Au final, le code était pondu beaucoup plus vite pour des programmes un peu importants.
<p>- La gestion des écrans n’est pas simpliste, elle est bizarre : jamais vu ailleurs, jamais compris la cohérence. Pour des écrans texte 80 colonnes ça devait aller mais nous sommes au XXIè siècle. Oracle utilise un outil du genre de ce qu'on trouvait en RAD dans les années 90, <i>Forms</i> (moche et assez limité mais à peu près utilisable, créant de vrais fenêtres avec ascenseurs, boutons...), en attendant le <i>full web</i>.<br>Par contre, pour les sorties papier, <i>Smartforms</i> (un cauchemar d’ergonomie) n’arrive pas à la cheville de Oracle Reports, un outil de dix ans plus ancien.
<p>Un bémol, la gestion des <i>matchcodes</i>, SELECT-OPTIONS, PARAMETER, l’intégration avec les filtres... est un point fort de SAP/ABAP que je regretterais si je retournais sous Oracle Applications.
<p>- La programmation objet, je suis d’accord, n’est pas vraiment adaptée au fonctionnement des ERP, mais c’est une question de style ; le point fort est plutôt dans la gestion des interfaces graphiques, encore faut-il que cela soit fait correctement, l’adaptation au CRM m’a semble inutilement complexe (un défaut très SAP, je dirais même très allemand, la lourdeur façon ''Panzer'').
<p>- Oracle fait ça tout aussi bien, de manière plus agréable à mon goût car il se base sur une collection d’outils plus ou moins « standards » et non liés forcément à l’ERP, et le langage de développement est plus moderne et plus agréable (PL/SQL, proche du Pascal et du SQL). On pourrait rêver d’un mix des deux, du PL/SQL intégrant les <i>matchcodes</i> et éventuellement le typage « fonctionnel » des données.
<p>- Ouais, à moi aussi le temps manque... Merci des critiques constructives, en tout cas.
Des millions de lignes à travers le millefeuille - UKRAINIENurn:md5:d97998c207b5d228d72a29949fa3af852007-02-13T17:37:45+00:002007-02-13T17:37:45+00:00UKRAINIEN<p>D'accord pour le côté commercial, j'ai connu 2 projets qui ont planté pour un mauvais choix de l'ERP, à savoir SAP, qui n'était pas le meilleur choix pour le métier du client.<br />
<br />
Mais tous les clients ne font pas confiance qu'aux commerciaux dans leur choix. En fait la pertinence du choix repose sur le fait que l'on peut quitter SAP, car en fait cela représente très peu en rapport du C.A. des grandes sociétés, parfois 1 ou 2%. Et ces sociétés ne le font pas.<br />
<br />
L'ABAP OBJECT a de bons points, en rapport à JAVA, la gestion des données en permettant de se référer au dictionnaire de données. Le problème de transtypage est commun à tous les langages, l'ABAP n'y échape pas.<br />
<br />
Je suis resté sur ORACLE au PL/SQL, je ne peux pas me permettre de comparer au-delà. Cela étant dit, il faut donc voir toutes les facettes du langage.<br />
<br />
Pour l'abap : <br />
le SQL (avec ses syntaxes particulières)<br />
la gestion par des tables internes (que je trouve excellente, car figée les données à un instant me semble très important)<br />
la gestion des écrans, simpliste (parfois un peu trop)<br />
La programmation interactive<br />
la programmation object (encore faut-il l'aimer, parfois pas très adaptée au besoin, et complexifie la programmation, quelle que soit le langage. Ce n'est que mon avis).<br />
<br />
Oracle fait-il tout cela? Personnellement je ne sais pas. Et je ne connais pas le niveau de complexité pour le faire.<br />
<br />
<br />
Pour ce qui est de mes stagiaires, tous ne sortent pas d'école, certains avaient plus de 15 ans de programmation derrière eux.<br />
<br />
J'ai lu aussi tes réponses sur les autres messages. Pardon, je ne peux y à répondre à toutes, le temps me manque. Je n'ai pas essayé de te convaincre, juste de présenter mon point de vue.<br />
<br />
</p>Des millions de lignes à travers le millefeuille - Le webmestreurn:md5:7b06eaf564bfb3efa5bc59c92612db302007-02-12T21:22:30+00:002007-02-12T21:26:57+00:00Le webmestre<p><b>@UKRAINIEN</b> : Oui, j’avoue une préférence pour Oracle (du moins j’aime la base de données, et l’utiliser ; l’administrer est plus chinois ; l’ERP est mieux foutu mais moins puissant que SAP, avec ses propres limites ; les autres outils sont très inégaux ; quant à l'entreprise elle-même, elle est à baffer.<br>Pour le mandant, je n’ai pas voulu détailler. Ça fait partie des bonnes idées du produit (je passe sur quelques incohérences d’implémentation, du genre des Sapscripts mandants-dépendants quand les programmes sont interdépendants, mais bon...).<br>L’ABAP a pas mal évolué, oui, mais R/3 ne se programme pas encore en ABAP objet là où je bossais. Le peu que j’ai vu du développement sur le CRM avec sa boulimie de classes m’a effrayé ; j’ai failli pleurer quand je me suis aperçu que l’utilisation en paramètres de fonctions de variables de même type sous-jacent (entiers, chaînes...) mais de domaines différents que celui attendu provoquait des plantages (à l’éxécution !!!), obligeant à une orgie de transtypage. (Mais bon, l’expert qui me pilotait sur ce sujet précis était peut-être une burne qui ne connaissait pas les astuces...).<br>Les points positifs, il y en a, mais comme dit sur un autre billet, il ne sont pas liés au développement (sinon à la facilité de trouver des gens pour écrire les programmes, en général en Inde). Quant à l’argument d’avoir été choisi par les plus grandes sociétés... je connais assez le milieu et les commerciaux pour savoir que c’est l’antithèse même du critère d’excellence technique :o)</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:b43b5dc368247053a5f4f49c9811ac7c2007-02-12T20:47:03+00:002007-02-12T20:47:53+00:00Le webmestre<p><b>@UKRAINIEN</b> : Il faut distinguer deux choses dans le développement : la logique interne, et la facilité de le faire avec des outils correct. Pour la première, c’est un choix ; la seconde en découle cependant directement même si ce n’est que de la « technique » ; une erreur de <i>design</i> et un programme marche, mais en claudiquant.<br>SAP a choisi de ne pas tenir compte de décennies de recherche sur les bases de données (car fondamentalement c'en est une, avec des tables bien rangées), et de s'en tenir à un modèle de données antédiluvien (développé il y a longtemps) ou démentiellement moderne (CRM) ; idem pour le langage qui a des limites et une rigidité qui ne se sont plus de ce siècle, et rendent le développement très pénible pour qui est attaché à un minimum d’élégance et de compacité ; les outils sont plus ou moins imposés et représentent un <i>patchwork</i> de générations différentes, et ce ne sont pas les plus récents les mieux conçus (j’ai une haine particulière pour le pourtant récent <i>Smartforms</i>) ; la base sous-jacente est sous-exploitée (le SQL de l’ABAP n’arrive pas à la cheville de celui de la base Oracle sous-jacente ) ; l’interface est le type même de ce qu’il ne faut pas faire en ergonomie. Il est clair qu’une masse énorme de travail permet à la chose de tenir debout, mais c'est d'abord à sa richesse fonctionnelle qu’elle le doit (et là, chapeau). Je ne nie pas que quelques gadgets embellissent parfois la vie (je regretterai les <i>matchcodes</i>), mais si peu... La doc ne manque pas mais elle est boursouflée et très lourde. Les interfaces de programmation (fonctions, BAPIs, <i>user exits</i>...) se sont empilées au fil des modes et leur maniement est parfois délicat ou abscons. Dernier et très gros reproche, les standards sont totalement méprisés sur à peu près tous les plans (SAP se veut le standard).<br>En tant que développeur, ce fut un calvaire, mais comme je l’ai dit, je ne suis pas la cible et la facilité de développement n’est pas l’argument de vente. </p>Des millions de lignes à travers le millefeuille - UKRAINIENurn:md5:3837c11fcd2dff6171adad705ecfe4e32007-02-12T13:35:51+00:002007-02-12T13:35:51+00:00UKRAINIEN<p>Décidément,<br />
<br />
vou seriez pour oracle que je ne serai pas surpris. (:)) Mais c'est votre droit.<br />
<br />
La notion de mandant va au-délà de ce que vous enoncez. Il est aussi possible de rajouter des index sur les tables, jusqu'à 12, mais comme vous le savez "trop d'index tue l'index". C'est une décision à prendre par les administrateurs SAP.<br />
<br />
il y a eu de nombreuses améliorations dans les requêtes ABAP, sans que vous le voyez. Comme c'est un langage interprété compilé, les optimisations peuvent être faite sans pour autant changer la syntaxe.L'ABAP est un langage qui a beaucoup évolué au cours des 5 dernières années.<br />
<br />
SAP n'est pas considéré comme une bête de course, je partage votre point de vue. Mais comme il a été choisi par les plus grandes sociétés dans le monde, il a aussi des points positifs.<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - UKRAINIENurn:md5:485315adeaae500f7a1d0a28e8fd91252007-02-12T13:17:40+00:002007-02-12T13:17:40+00:00UKRAINIEN<p>Bonjour,<br />
<br />
Le principe de SAP se résume en 3 mots : intégrité, portabilité, scalabilité. Pour ce qui concerne l'intégrité, je ne répondrai que sur la partie développement, c'est mon métier et il y a déjà beaucoup à dire.<br />
Si vous allez intégrer directement dans les tables, c'est tout à faite possible, mais vous ne respecterez pas les règles métiers définies par le consultant fonctionnel. Les réintégrer dans un programme est refaire le travail du consultant fonctionnel, ou de SAP.<br />
<br />
Les problèmes que vous présentez dans la gestion des données concerne un problème de réplication, avec des données modifiées. Cela se gère très bien dans SAP, en passant par les fonctions adéquates, ou même dans un programme spéficique, à la condition de connaitre les bonnes zones.<br />
<br />
Il est vrai qu'il n'est pas toujours facile de travailler avec SAP, et on peut parfois s'arracher les cheveux. Mais si SAP est numéro 1, ce n'est pas pour rien. Il a aussi de nombreux avantages.<br />
<br />
Vous aurez en juillet/aout prochain un livre en français sur l'ABAP, qui présentera les concepts SAP. J'en suis l'auteur. Aux editions ENI.</p>Initialiser tu n’oublieras pas ! - Le webmestreurn:md5:d173155340981db1812b2b943bf5841d2006-12-21T21:37:00+00:002007-02-11T11:19:36+00:00Le webmestre<p><b>@Stéphane</b> : Oui, un peu. Disons que le vrai problème, là, est que le compilo laisse passer le fait qu'on rencontre deux fois la même variable à la suite, plus que le fait qu'il ne veuille pas recréer la case mémoire qui va bien.
Courage, plus que 2 semaines à subir ce langage...</p>Initialiser tu n’oublieras pas ! - Stephurn:md5:6ba0debb161a04ee9fd34e6e166a85562006-12-20T18:46:59+00:002006-12-20T18:46:59+00:00Steph<p>OK, là du coup c'est plus effrayant, oui.<br />
C'est un équivalent d'un "static" en C qui serait implicite... ?</p>Initialiser tu n’oublieras pas ! - Le webmestreurn:md5:bfbf68b88c4e3d6be2ab537d5da843352006-12-20T17:15:47+00:002006-12-20T17:15:47+00:00Le webmestre<p><b>@Stéphane</b> : Heu... C'était pour voir s'il y avait quelqu'un qui <strike>lisait</strike> suivait... :o)<br> Sérieusement, oui, la ligne DATA est au-dessus du IF, et effectivement ça ne passerait pas, et elle n'est pas non plus réinitilalisée. D'ailleurs le code foireux que tu as pointé compile aussi, j'ai vérifié, et c'est également effrayant... </p>Initialiser tu n’oublieras pas ! - Stephurn:md5:a90ee54c023de062cc55faa1e831a5b42006-12-20T11:28:40+00:002006-12-20T11:28:40+00:00Steph<p>Je ne connais pas ABAP du tout, mais dans ton exemple<br />
----------<br />
IF x-un_champ = ... .<br />
. DATA v TYPE c VALUE '0'.<br />
. v = c_une_valeur.<br />
.ENDIF.<br />
. compteur = compteur + v + x-un_autre_champ.<br />
----------<br />
tu déclares bien v à l'intérieur du IF/ENDIF, et tu l'utilises pourtant en dehors dans ta sommation ?<br />
<br />
Je ne vois pas comment il devrait réagir, mais en C si tu fais.<br />
---------------<br />
if x->champ {<br />
montype v = 0;<br />
v = c->valeur;<br />
}<br />
compteur = compteur + v + x->un_autre_champ;<br />
---------------<br />
tu vas te prendre une erreur du compliateur, bien sur...<br />
<br />
Qu'ABAP le permette me parait plus une faute que le fait qu'il n'initialise pas.</p>Initialiser tu n’oublieras pas ! - Baliseurn:md5:c326dc9b08e6d75b218efb5f57ce1e362006-12-19T22:37:48+00:002006-12-19T22:37:48+00:00Balise<p>AAAAAAAAH mais quelle horreur :(((</p>Par paquets de 5 - Le webmestreurn:md5:71f6d6cc5da6a5bc3aac0e897194c67f2006-11-17T09:41:35+00:002006-11-17T09:42:16+00:00Le webmestre<p><i>Balise</i>>Effectivement, mon entretien annuel, ça a donné à peu près ça :o) <br>Et j’en ai tiré les conséquences puisque je pars et du client et de ma SSII trop spécialisée sur SAP dans la région.</p>Par paquets de 5 - Baliseurn:md5:6f8ee6678b545d70311218c1ed2f1f072006-11-16T22:35:48+00:002006-11-16T22:35:48+00:00Balise<p>J'aime. Et après, en entretien : « Y a-t-il des choses que vous ne souhaitez pas faire ? - Du SAP. - Ah, pouquoi ça ? ».</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:e11a47ebfc5546f7ecb9771a4298a8af2006-11-09T17:54:07+00:002006-11-09T17:57:33+00:00Le webmestre<p><i>Raspberry92</i> > Les modèles de données complets comportent des milliers de table. Et cela dépend du nombre de modules installés. Dans le cas d’Oracle, on peut se débrouiller un peu avec les nom, mais le modèle de SAP R/3 est vraiment cryptique, avec ses noms de tables de 4 lettres, acronymes de mots en allemand. C’est pour quelle utilisation ?
<br>Soit dit en passant, toutes les docs que j’ai vues sur le sujet indiquent que l’information est confidentielle (non que ce soit vraiment un joyau, mais la chose doit ).
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Raspberry92urn:md5:048d983a546f85f550c08dc475ab241d2006-11-09T17:40:22+00:002006-11-09T17:40:22+00:00Raspberry92<p>Bonjour,<br />
savez vous si il est possible de récupérer les datamodels de ces deux ERP ?<br />
Cordialement,<br />
</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - JELMANSurn:md5:61d049832a8456b564d73b750719a4612006-10-23T21:34:46+00:002006-10-23T21:34:46+00:00JELMANS<p>bonjour..pourriez vous m'avoir les codes et types de mouvements pour sap r/3 de magasinage du stock... out-ind-mix-ensachage produits ect.....merci a+++</p>Les joies de l’ERP et du CRM (II) - Le webmestreurn:md5:0b1494d5a6617ac43d172ec965c356832006-10-01T15:31:16+00:002006-10-01T15:31:16+00:00Le webmestre<p>Corrigé le lien...</p>Les joies de l’ERP et du CRM (II) - anteaneurn:md5:a6d17e91f01abb1e13c1fc59ffd37c2d2006-09-28T17:08:36+00:002006-10-01T15:29:57+00:00anteane<p>Bonjour,<br />
<br />
Je viens de rédiger un article sur les grandes étapes de la mise en place d’un ERP( <a href="http://www.anteane.fr/dotclear/index.php?2006/09/28/17-erp-gpao-quelles-etapes-pour-la-mise-en-place-l-exemple-pmi-soft" title="http://www.anteane.fr/dotclear/" rel="nofollow" rel="ugc nofollow">www.anteane.fr/dotclear/...</a> Je prends l’exemple de PMI SOFT. Je pense qu’aujourd’hui les ERP s’ouvrent vers de nouveaux marchés, les PME par exemple et que la mise en place se simplifie de plus en plus tout en gardant l’essentiel et surtout la fonctionnalité et l’efficacité. J’attends des réactions à ce sujet.<br />
<br />
merci </p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - Le webmestreurn:md5:36170a9053424a28804b83254bd753272006-09-05T20:44:20+00:002006-09-05T20:44:20+00:00Le webmestre<p>Et bien giao, profite d’Oracle tant que tout le monde n’est pas encore passé sous SAP :o)</p>La Guerre des ERP : SAP vs Oracle Applications (5) : Schémas de données - giaourn:md5:3b5310ffd844076dd88833654e7c76482006-09-05T18:47:49+00:002006-09-05T18:47:49+00:00giao<p>merci pour ce début de commencement d'explication sur les différences intrinsèques entre Oracle et SAP. Je travaille sur OAP depuis 1999 et je trouve ton exposé très pertinent. Malheureusement, ma connaissance de SAP est nulle mais l'étude comparée permet d'en concevoir quelques aspects. bien cordialement.</p>Les joies de l’ERP et du CRM (III) - Jidurn:md5:a7f3658094dbbbf187ff69be026128612006-03-16T12:39:11+00:002006-03-16T12:39:11+00:00Jid<p>Tous les ans, on a un nouveau logiciel qui arrive pour aider à gérer la production informatique : des trucs foireux qui te sortent des diagrammes illisibles même pas compatible windows (hardcopy d'écrans moches dans les documents).<br />
Vu le nombre de logiciels déployés (et donc payés), ils sont tous sous-utilisés, c'est frustrant!</p>Les joies de l’ERP et du CRM (III) - Le blogmestreurn:md5:d6bc028a0b46cdd25afc43d06b1eac072006-03-15T18:42:32+00:002006-03-15T18:42:32+00:00Le blogmestre<p>Tu as joué avec ?</p>Les joies de l’ERP et du CRM (III) - Jidurn:md5:9da6d91fdd2c2e6318c9d138318ee5ae2006-03-15T12:47:02+00:002006-03-15T12:47:02+00:00Jid<p>"J'ignore leur prix, il doit être aussi indécent que leur utilité est grande."<br />
et pourtant leur mise en application est souvent inefficace</p>