none
MDS API - TransactionsGet & TransactionSearchCriteria

    Dotaz

  • I am working through a proof-of-concept.  I need to look up some transaction data in a external workflow initiated by a HasChanged business rule.  I have the business rule passing member information to the workflow, this includes version name, version id, model name, model id, member name and member id.  The id values passed to the external workflow are integers (not guids / muids).  

    Initial idea is to then use these values when using the MDS API to search transaction information, but I find confusing behavior.  If I set the Identifier.Name property on the TransactionSearchCriteria.VersionId & TransactionSearchCriteria.ModelId & TransacdtionSearchCriteria.EntityId properties, then I find happy little transactions.  If I attempt to use the Identifier.InternalId property of the TransactionSearchCriteria.VersionId & TransactionSearchCriteria.ModelId & TransacdtionSearchCriteria.EntityId properties, then I find unhappy errors.  Code samples below:

    Does not work (results will contain errors)

                Transaction[] transactions;
                int recordCount;
                var searchCriteria = new TransactionSearchCriteria
                {
                    ModelId = new Identifier { InternalId = 1 },
                    VersionId = new Identifier { InternalId = 1 },
                    EntityId = new Identifier { InternalId = 1 },
                    MemberId = new MemberIdentifier { InternalId = 1 },
                };
    
                // get the transactions matching the search criteria
                var result = service.TransactionsGet(new International(), searchCriteria, out recordCount, out transactions);
    

    This bit will work however: 

    	    Transaction[] transactions;
                int recordCount;
                var searchCriteria = new TransactionSearchCriteria
                {
                    ModelId = new Identifier { Name = "myModelName" },
                    VersionId = new Identifier { Name = "myVersionName" },
                    EntityId = new Identifier { Name = "myEntityName" },
                    MemberId = new MemberIdentifier { Code = "myMemberCode" },
                };
                
                // get the transactions matching the search criteria
                var result = service.TransactionsGet(new International(), searchCriteria, out recordCount, out transactions);
    

    Can someone please explain?

    10. srpna 2012 16:37

Odpovědi

  • Hi James,

    Sadly, you are right, when I reprod it on my machine I had newer version which already expose the member MUID. This is something which is really missing from the SQL 2012 version.

    You can have a workaround for this one by calling EntityMembersGet for the specific member as you already have its code. this will return the member MUID so you can later use if for getting the transactions. You can also get all the transactions by Code but then you will not get transactions for members which their code was changed.

    Thanks, Tomer (MSFT)

    22. srpna 2012 21:53
    Moderátor

Všechny reakce

  • The InternalId attribute is for system use only, Name or Id is correct attribute to use in your code

    Yang Wang (Microsoft SQL Server Master Data Services)

    14. srpna 2012 19:46
  • The InternalIds are not supposed to be used externally.

    It is probably wrong that you even get those when you start a workflow, but anyhow, you should not try to use them.

    Thanks, Tomer (MSFT).

    14. srpna 2012 19:46
    Moderátor
  • Wait, Seriously?  This object is generated from the WCF discovery service and exposes things that you "just shouldn't touch."  Huh?  We can do better guys.

    1) It should work.  How much work are we talking about to wire up this property in the service & in the stored proc that backs this call?  Not much. I've looked.

    OR

    2) It shouldn't be visible

    OR

    3) It should be read-only

    So what piece of unchangeable member information gets passed from the business rule to the workflow that will allow me to look for matching transactions?  Nothing?  The Muid doesn't get passed, only what equates to the InternalId (right?).  Obviously code & name come in as options for searching transactions, but those don't work as those attributes can change.  Am I missing something?

    15. srpna 2012 14:29
  • Hi James,

    Thank you for your question.  

    I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated.  

    Thank you for your understanding and support. 

    Thanks,
    Bin Long

    Bin Long

    TechNet Community Support

    17. srpna 2012 6:04
    Moderátor
  • Hi James,

    I just tested this scenario and I see the members MUID in the XML which is sent to the workflow. You should be able to use this MUID and get the transaction history.

    Do you see otherwise? if so, you should look on the Service Broker queue named ExternalActions and send us the content of the message.

    Thanks, Tomer(MSFT)

    17. srpna 2012 20:27
    Moderátor
  • Sorry for delay.  Here's the XML I get from the business rule.  No Member_MUID or similar.

    <?xml version="1.0"?>
    <ExternalAction>
      <Type>CHG_HISTORY</Type>
      <SendData>1</SendData>
      <Server_URL>State_List</Server_URL>
      <Action_ID>State_List_Name_Changed</Action_ID>
      <Model_ID>7</Model_ID>
      <Model_Name>LCCA</Model_Name>
      <Entity_ID>1066</Entity_ID>
      <Entity_Name>State List</Entity_Name>
      <Version_ID>7</Version_ID>
      <MemberType_ID>1</MemberType_ID>
      <Member_ID>2</Member_ID>
      <MemberData>
        <ID>2</ID>
        <Version_ID>7</Version_ID>
        <ValidationStatus_ID>3</ValidationStatus_ID>
        <ChangeTrackingMask>0</ChangeTrackingMask>
        <EnterDTM>2012-07-16T16:57:08.567</EnterDTM>
        <EnterUserID>1</EnterUserID>
        <EnterUserName>domain\userName</EnterUserName>
        <EnterUserMuid>7A70919F-76FC-451D-B371-11610A1EACA1</EnterUserMuid>
        <EnterVersionId>7</EnterVersionId>
        <EnterVersionName>VERSION_1</EnterVersionName>
        <EnterVersionMuid>A8189E91-E933-462D-B76E-C124E8A444AC</EnterVersionMuid>
        <LastChgDTM>2012-07-16T16:57:08.567</LastChgDTM>
        <LastChgUserID>1</LastChgUserID>
        <LastChgUserName>domain\userName</LastChgUserName>
        <LastChgUserMuid>7A70919F-76FC-451D-B371-11610A1EACA1</LastChgUserMuid>
        <LastChgVersionId>7</LastChgVersionId>
        <LastChgVersionName>VERSION_1</LastChgVersionName>
        <LastChgVersionMuid>A8189E91-E933-462D-B76E-C124E8A444AC</LastChgVersionMuid>
        <Name>California</Name>
        <Code>CA</Code>
      </MemberData>
    </ExternalAction>

    22. srpna 2012 21:11
  • you should look on the Service Broker queue named ExternalActions and send us the content of the message.

    Help me produce this please.  I am unsure of how to get the content you've requested.

    22. srpna 2012 21:18
  • Hi James,

    Sadly, you are right, when I reprod it on my machine I had newer version which already expose the member MUID. This is something which is really missing from the SQL 2012 version.

    You can have a workaround for this one by calling EntityMembersGet for the specific member as you already have its code. this will return the member MUID so you can later use if for getting the transactions. You can also get all the transactions by Code but then you will not get transactions for members which their code was changed.

    Thanks, Tomer (MSFT)

    22. srpna 2012 21:53
    Moderátor
  • SP1?  When does this go to GA?
    22. srpna 2012 22:04
  • As there is easy workaround I think this will be public only in the next major version.

    If you dont have valid workaround you should open a CSS incident for driving this for earlier releases.

    Thanks, Tomer (MSFT).

    22. srpna 2012 22:57
    Moderátor