1 / 26

Business Layers

Business Layers. Defining Simple Open Interchange Constructs. February 12, 2002 Workshop. Task Force DoD Namespace. Consensus is extremely difficult. …so we need to look for other ways, complementary mechanisms for alignment. Standardizing of APIs & Constructs. Influences

kaycee
Download Presentation

Business Layers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Business Layers Defining Simple Open Interchange Constructs February 12, 2002 Workshop Task Force DoD Namespace

  2. Consensus is extremely difficult …so we need to look for other ways, complementary mechanisms for alignment.

  3. Standardizing of APIs & Constructs Influences • XML/edi Framework • CommerceNet’s eCo Architecture • Hewlett Packard’s eSpeak • Global Uniform Interoperable Data Exchange – GUIDE • SEF/IMDEF Implementation Guideline Markup Language (igML) • Universal Registry - UREP XMI Current Work • ISO/IEC 11179 • ebXML Specifications • eBTWG– on going

  4. Verb: Create, Remove, Update, Delete Motive: Use indicator, i.e. ReasonCode Context Select resolution, which elements used Make ‘Optional’ elements ‘Mandatory’ Subset/Extend standard codelists Constraints • Registry UID • Versioning • Typing: Classwords • Relationships: • - Classifications • - Associations to other components Address Connection Construct Components Address Component Meets business requirements

  5. Model for Mechanisms Collaboration Partner Agreements Collaboration Partner Profiles 5 Contract BP Specification 4 Workflow Process XForms Specifications Schema 3 Messages Assemblies Artifact relationships 2 Motivation Time People Presentation Rules Events Roles Directory Services Data/Codes Services/Functions Network 1 MSH/SOAP Nouns Verbs Transport Routing, Packaging WSDL Source: Lubash Pyramid

  6. Registry’s Role: Open Active Mechanisms 5 DoD XML Registry Contract Open Constructs 4 Workflow Process 3 Specifications Schema Messages Artifact relationships 2 Motivation Time People Presentation Rules Events Roles Directory Services Data/Codes Services/Functions Network 1 Nouns Verbs Transport Routing, Packaging Open API

  7. Realizing the Full Benefits of eBusiness Mapping (Today) Templates (Future) App App Std Domain Trans Trans IC Map IC Instance Template Instance Specific Across Domain Trans Map Registry Preferred App App

  8. Open API/Constructs allows for:‘Help From Above’ Collaboration Partner #1 Collaboration Partner #2 Business Information DoD SHADE Registry XML Instance XML Instance Data <ItemNo>41358</ItemNo> <UnitNo>41358</UnitNo> Machine-to-Machine <Color>Green</Green>

  9. Assembly Doc Addresses Level 3 Needs Collaboration Partner Agreements Collaboration Partner Profiles 5 Contract BP Specification 4 Workflow Process XForms Specifications Schema 3 Messages Assemblies Artifact relationships 2 Motivation Time People Presentation Rules Events Roles Directory Services Data/Codes Services/Functions Network 1 MSH/SOAP Nouns Verbs Transport Routing, Packaging WSDL Source: Lubash Pyramid

  10. Core Component Realisation (CCR) Assembly Doc Approach and Technical Details

  11. Assembly DocObjectives and Focus • Introduction • Provide linkage between architecture design stack and payload formats. • Design Constraints • Suitable for use by technical business users, not just programmers • Re-use of XML specifications toolset • Support use of Core Components • Provide Registry facilitation • Provide support for legacy transaction formats • Support BPSS provision for substitution transaction formats

  12. Architecture Components

  13. Implementation Overview Design Time UML / XMI Context AssemblyDoc Content Map

  14. Business Needs • Ensure that the logical model and the physical implementation are tightly coupled • Lesson learned – developing ‘standard’ examples leads to gap between what people actually use.

  15. How do we implement this? What technology pieces work and how do we leverage them?

  16. Technology Toolbox • Schema / DTD – describe the structure set – but weak at describing the instance set, ie: (A,B | A&B | A | B) • Old = IMPDEF – how UN/EDIFACT does this stuff for EDI, but no good for XML • XSLT – procedural tool, good for XML, not others • Schemotron / Examplotron – validation-centric • Simple well-formed XML – more expressive than DTD! • XPath – good tool for describing constraint rules • Need declarative approach – not procedural • No runtime surprises! All content must be pre-determined.

  17. Technical Approach • Need the 3 pieces: • Structural definition • Neutral XML means to define actual instance model • Constraint rules • Use XPath • Use “Examplotron” style in-line action statements • Use Declarative predicates • Content Referencing • Registry based • In-line based

  18. AssemblyDoc = A, B, C! <AssemblyDoc> <AssemblyStructure> <BusinessUseContext> <ContentReference> </AssemblyDoc>

  19. AssemblyDoc Structure Details <AssemblyDoc> <AssemblyStructure> <POST_JOURNAL as:id=“JournalDetails” > <JEHEADER> <AMOUNT qualifier="DOCUMENT" type="T"> <VALUE>2340500</VALUE> <NUMOFDEC>2</NUMOFDEC> <SIGN>+</SIGN> <CURRENCY>USD</CURRENCY> <DRCR>D</DRCR> </AMOUNT> <DATETIME qualifier="DOCUMENT" type="T"> <YEAR>%</YEAR> <MONTH>%</MONTH> <DAY>%</DAY> <HOUR>%</HOUR> <MINUTE>%</MINUTE> <SECOND>%</SECOND> <SUBSECOND>0000</SUBSECOND> <TIMEZONE>-0500</TIMEZONE> </DATETIME> and so on….. Start with what you want!

  20. AssemblyDoc Context Details <AssemblyDoc> <AssemblyStructure> </AssemblyStructure> <BusinessUseContext> <!-- optional section to configure structure assembly template --> <Rules> <context> <!-- default structure constraints --> <constraint action="makeoptional(//MetaInformation/annotation)" /> <constraint action="makerepeatable(//Association)" /> <constraint action="makeoptional(//Association@registry)" /> </context> <context condition="token='ComponentType' and contains(value,'noun')"> <constraint condition="/token='use' and /value='element'" action="excludeTree(//Processes)" /> </context> <context condition="token='ComponentType' and contains(value,'logical')"> <constraint action="excludeTree(//PhysicalDetail)" /> <constraint action="makeoptional(//PhysicalDetail)" /> </context> </Rules> Also can use includes to pull in the rules instead in-line

  21. Context Rules Functions • Small set – declarative approach to controlling instance: • excludeTree ([XPath]) • excludeElement ([XPath]) • excludeAttribute ([XPath]) • makeoptional ([XPath]) • makemandatory ([XPath]) • makerepeatable ([XPath]) • useChoice ([XPath]) • setValue ([XPath],[string]) • restrictValues ([XPath],[UID]|[string,string..]) • replaceValues ([XPath],[UID]|[(match,replace),(match,replace)…] • Supports use of logic analyzer to detail parameters / rules, and also “pretty print” for business designer / analyst.

  22. Content Reference Section <ContentReference> <item name="Label" UIDReference="UNCC010015" taxonomy="UID" registry="UNCC" /> <item name="City" type="text" maxLength="30" /> <item name="Description" UIDReference="UNCC010016" taxonomy="UID" registry="UNCC" /> <item name="ExtensionDefinitions" UIDReference="UNCC010017" taxonomy="UID" registry="UNCC" /> <item name="PhysicalDetail" UIDReference="UNCC010018" taxonomy="UID" registry="UNCC" /> <item name="Constraints" UIDReference="UNCC010019" taxonomy="UID" registry="UNCC" /> <item name="ExtendedDetails" UIDReference="UNCC010023" taxonomy="UID" registry="UNCC" /> <item name="Processes" UIDReference="UNCC010024" taxonomy="UID" registry="UNCC" /> <item name="Associations" UIDReference="UNCC010025" taxonomy="UID" registry="UNCC" /> <item name="Association" UIDReference="UNCC010026" taxonomy="UID" registry="UNCC" /> <item name="Schemas" UIDReference="UNCC010027" taxonomy="UID" registry="UNCC" /> <item name="Context" UIDReference="UNCC010028" taxonomy="UID" registry="UNCC" /> </ContentReference>

  23. From AssemblyDoc to Content Map • The AssemblyDoc defines the structural formatting and the business rules for the transaction content. • This then drives the implementation step of linking the derived final contextual details to the actual application information. • Declarative approach – stating input / output path locations.

  24. Example content map <MapStructure> <Rules> <MapRule output="Product List" input="@PARENT()" path="" /> <MapRule output="type" input="Sales/Company/Year/Qrt/Product@type" /> <MapRule output="name" input="Sales/Company/Year/Qrt/Product/Item@name" /> <MapRule output=“madeby" input="Sales/Company/Year/Qrt/Product/Item@manf" /> <MapRule output="value" input="Sales/Company/Year/Qrt/Product/Item@value" /> <MapRule output="sold" input="Sales/Company/Year/Qrt/Product/Item@sold" /> <MapRule output="Product List" input="@ENDPARENT()" /> </Rules> </MapStructure>

  25. Summary • Uses well-formed XML structure with in-line directives to describe content model and supports legacy formats. • Uses XPath and declarative predicates to state the MIG (message implementation guidelines) in machine accessible format. • Couples to the business context of BPSS / CPA via partner parameter profile document and link from the BPSS. • Allows for localization and substitution structures • Provides referencing to component semantics in registry or inline locally. • Makes consistent assembly possible, and drives adoption of simple transaction structures.

  26. UN/CEFACT SIMPLE, TRANSPARENT AND EFFECTIVE PROCESSES FOR GLOBAL BUSINESS.

More Related